LibreFang 2026.7.21 发布：安全审计与多用户隔离

LibreFang 2026.7.21 正式发布，自 v2026.7.11 以来共合并 61 个 PR，来自 4 位贡献者。本次更新重点强化了多租户数据隔离与凭证管理，并扩展了 MCP 集成。

安全与多用户隔离
用户可自带 LLM 提供商 API Key，支持按所有者追踪消耗；运营者可设置组织级提供商白名单并在 API 层强制每人预算。
知识图谱已按用户分区，修复跨用户数据泄漏；MCP 桥接层加强跨账户频道发送限制；会话专属压缩摘要防止 prompt 泄漏。
四轮安全审计修复了 15+ 个漏洞，涵盖授权缺口与令牌配额竞争。

开发者体验
新增 MCP resources 原语，Agent 可直接访问 MCP 暴露的资源。
长时间运行任务在 Slack 上通过 Block Kit 消息编辑实时展示阶段进度。
仪表盘 Hands 面板内可在线编辑 HAND.toml 清单。
所有 sidecar 适配器现支持快捷预设目标通道。

基础设施与提供商鲁棒性
Gemini 与 Vertex AI 驱动新增 response_format 支持；优先使用实时模型目录（构建时回退）。
令牌配额释放时保留预留以防止自我 DoS；提供商别名规范化防止扣费泄漏。
路由中出现的提供商错误现在会准确暴露，不再返回乱码或空轮次。

其他修复与维护
包括权限、环境变量信任、会话锁、MCP 参数过滤、上传路径规范化等多项修正。
依赖升级：tokio-tungstenite、wasmtime、serde_with 等。
迁移至 agent-client-protocol 1.3.0。

安装 / 升级
Binary: curl -fsSL https://get.librefang.ai | sh
Rust SDK: cargo add librefang
JavaScript SDK: npm install @librefang/sdk
Python SDK: pip install librefang-sdk

GitHub 完整更新日志及发布页面见素材链接。

#开发者 #工具 #LibreFang #AI #多租户 #MCP #Rust #安全审计
@DevToolboxHub

.NET 11 Preview 6 发布：C#、ASP.NET、MAUI、EF 同步更新

微软推出 .NET 11 Preview 6，覆盖 C#、ASP.NET Core、MAUI 及 Entity Framework Core 多个组件。C# 方面，扩展成员新增索引器支持，允许在扩展块中为现有类型添加索引访问；同时引入内置联合支持类型。

ASP.NET Core 带来异步验证、自动 CSRF 保护，并默认启用 OpenAPI 3.2。MAUI 将 CollectionView 支持扩展到 Windows 平台。EF Core 新增 FULL OUTER JOIN 翻译能力。

本次预览版进一步完善了语言特性和框架能力，适合 .NET 开发者先行试用评估。

#开发者 #工具 #NET11 #CSharp #ASPNETCore #MAUI #EFCore
@DevToolboxHub

Java 周报：JDK 28 新 JEP、Simple JSON API 等

本期 Java 周报（2026 年 7 月 20 日）汇总了多条重要动态：两项 JEP 拟纳入 JDK 28、Oracle 发布 2026 年 7 月关键补丁更新、Embabel 1.0 正式 GA、Azul Payara 7.2.0 与 Helidon 4.5.1 同步更新。

JDK 28 候选 JEP
• JEP 540：Simple JSON API（孵化器）——为 Java 提供轻量 JSON 处理能力
• JEP 541：Deprecate the macOS/x64 Port for Removal——计划移除 macOS/x64 移植版

安全与补丁
• Oracle 2026 年 7 月关键补丁更新（CPU）

工具与框架 Release
• Embabel 1.0 GA：首个稳定版
• Azul Payara 7.2.0：基于 Payara Server 的发布
• Helidon 4.5.1：快速迭代的微服务框架新版本

以上动态涵盖了 Java 语言演进、安全更新与主流工具的新版本，开发者可重点关注 JEP 540 带来的原生 JSON API 雏形。

#开发者 #工具 #Java #JDK28 #SimpleJSONAPI #JEP #Embabel #Azul #Payara #Helidon #CPU2026
@DevToolboxHub

Agent 记忆可移植性：往返测试与方案

你的 agent 记忆存储在哪里？当框架出现破坏性变更、嵌入模型淘汰，或另一个 agent 需要第一个 agent 积累的上下文时，记忆能否真正迁移？一篇技术文章提出了「往返测试」来验证可移植性，并分析了 Open Knowledge Format (OKF) 与开源方案 Memanto。

记忆的核心不是读取问题，而是写入问题。当对话积累 400 轮时，哪些交互重要？事实被取代了怎么办？事件升级为记忆需要什么证据？谁断言、何时、依据什么、何时过期？忘记也是合规需求。这五个决策索引无法替你完成。

导出分为三级：原始轮次 tarball（需重跑提取管线）、含映射字段的结构化记录（可写导入器但丢失原因）、语义级记忆（含来源、时间边界、取代链）。市面上多数产品提供第一级却宣传第三级。

嵌入陷阱：若记忆的持久形式是 embedding，它就被绑定到嵌入模型。重新嵌入是隐式有损推导——零错误但检索质量沉默退化，三周后才显现。向量是缓存，将缓存作为记录系统等于被锁定。

多代理场景加剧问题：IDE agent、支持 agent、分析 agent 各自学习，存入各自存储，形状与规则不同，产生无协调机制的分歧。用户纠正了支持 agent，编码 agent 却永远相信旧事实。

OKF v0.1 于 2026 年 6 月由 Google Cloud Data Cloud 团队发布：一个目录的 markdown 文件 + YAML frontmatter，每个概念一个文件，交叉链接，唯一必需字段是 type。人类凌晨可读，Git 可做差异与审查，能超越技术栈存活。但 Satvik Singh 的基准显示，OKF 文档中有三个置信错误，检索放大之一：前 28 个结果中错误答案出现 26 次。bundle 是快照，记忆是过程。

往返测试（一个下午完成）：1) 从当前系统导出 ./snapshot-a；2) 导入干净实例；3) 从干净实例导出 ./snapshot-b；4) diff -r 检查。关注语义损失：取代链、来源、置信度/过期、交叉引用。若 B 的单元少于 A，有东西被静默丢弃。大多数系统至少失败三项。

往返测试是区分可移植性声明与可移植性保证的关键一步。无论当前使用何种记忆方案，都值得先跑一遍这个测试。文中还介绍了开源内存代理 Memanto（MIT 协议，v0.2.8 原生支持 OKF 集成与迁移，LongMemEval 89.8%，LoCoMo 87.1%）。

#开发者 #工具 #AgentMemory #OKF #Memanto #可移植性 #往返测试 #嵌入陷阱 #GoogleCloud
@DevToolboxHub

用 TypeScript ADK 构建 AI 代理

Google 的 Agent Development Kit（ADK）推出 TypeScript 原生版本，配合 Node.js 生态实现完全类型安全的 AI 代理开发。基于 Zod 模式定义工具参数，在编译期即可校验函数调用声明，减少运行错误。

示例项目是一个“Hello World”风格的天气和时间查询代理，整个代理逻辑集中在单文件 src/agent.ts 中，使用 Gemini 2.5 Flash 模型。工具返回判别联合类型，测试套件基于 Node 原生测试运行器，无需调用模型即可进行确定性测试。

开发者可通过 CLI 或 Web UI 本地调试，并一键部署到 Cloud Run。ADK 同时支持浏览器端运行，兼容 ESM 和 CommonJS。

设置步骤：需要 Node.js 20+、Gemini API 密钥或 Vertex AI 凭证。克隆示例仓库后执行 init.sh 安装依赖并生成 .env 文件，编辑认证方式后即可通过 npm start 或 npx adk run 启动交互式代理。

部署命令：npx adk deploy cloud_run --project "$GOOGLE_CLOUD_PROJECT" --region "$GOOGLE_CLOUD_LOCATION" --service_name "$SERVICE_NAME" --with_ui true src/agent.ts

ADK 目前版本 1.4.0，适用于需要快速构建、调试和部署 AI 代理的 TypeScript 开发者。

GitHub
GitHub

#开发者 #工具 #TypeScript #ADK #Gemini #Nodejs #CloudRun #AI代理
@DevToolboxHub

计算机网络面试复习笔记

一份入门友好且面向面试的计算机网络笔记，系统覆盖通信模型、协议、网络层、TCP/UDP、WebSocket/WebRTC 及常见面试题。详细对比和要点如下：

通信模型
客户端-服务器：集中式架构，所有请求经服务器处理，如 Google、Amazon。
P2P：设备直接通信，无中心服务器，如 WebRTC、Torrent。

协议速览
HTTP：请求-响应、无状态、运行于 TCP。
FTP：文件传输，使用控制连接和数据连接两条通道。
SMTP：发送邮件，使用 TCP。
IMAP：读取和同步邮件，邮件保留在服务器。
WebSocket：全双工、持久连接，但仍是客户端-服务器，非 P2P。
WebRTC：点对点通信，主要用 UDP，支持音视频和数据通道。

网络层要点
应用层：HTTP/FTP/SMTP/IMAP/WebSocket
传输层：TCP/UDP（TCP 可靠有序，UDP 快速尽力交付）
网络层：IP 寻址与路由

TCP vs UDP
TCP：面向连接，有 ACK 和重传，适合文件、银行、HTTP。
UDP：无连接，无确认，速度快，适合直播、游戏、视频通话。

重要面试问答
- FTP 用两条连接：一条命令，一条数据。
- 视频通话用 UDP：速度优先，丢帧可接受。
- WebSocket 不是 P2P，是客户端-服务器。
- SMTP 发邮件，IMAP 读邮件。

整份笔记对常见协议、层模型和面试题做了清晰梳理，适合快速复习和面试准备。

#开发者 #工具 #计算机网络 #网络协议 #TCP #UDP #WebSocket #WebRTC #面试
@DevToolboxHub

AWS 推出基于 VS Code 的 AI IDE Kiro，聚焦规格驱动开发

Kiro 是 AWS 基于开源 VS Code（Code OSS）构建的集成开发环境，内置专为规格驱动（spec-driven）开发优化的 AI 工具。它改变了传统的“先写代码再重构”流程，引导开发者从需求定义、技术设计到任务拆解，逐步完成实现。

Kiro 内置多个智能代理：Spec 代理负责规划阶段的特性需求、技术设计与任务列表；Plan 代理可分析代码库并协调工作流；Bug Fix 代理实时调试并修正错误。用户通过 AGENTS.md 文件配置项目核心指令与约束。

Kiro 的规格工作流（Kiro specs）遵循“需求 → 设计 → 任务”三步法，文件自动保存在项目根目录的 .kiro/ 隐藏文件夹中：

Requirements.md：根据用户指令生成用户故事与约束清单，支持提问细化。
Design.md：基于需求生成技术蓝图，包括数据模型、API 契约、组件图、文件结构及 TypeScript 接口等。
Tasks.md：将设计转为依赖感知的任务检查表，可逐条、分组或全量执行，UI 实时显示进度。

此外 Kiro 还提供 Autopilot（自动/监督模式）、Steering（按上下文定义规则）、Slash commands（自定义斜杠命令执行指令）、Checkpoints（对话检查点，可一键回退）以及自定义 Agent 等能力。

整体使用下来，Kiro 更像一个有思考能力的协作伙伴，而非简单聊天机器人；它帮助开发者更有条理地从规划阶段进入编码，适合追求结构化 AI 辅助的开发团队。

#开发者 #工具 #Kiro #AWS #AIAssistant #SpecDriven #VSCode #IDE #CodeOSS
@DevToolboxHub

免费GitHub Action填补付费代码扫描空白

2026年7月14日，GitHub在PR上推出AI安全检测，但明确仅限GitHub Code Security（即GitHub Advanced Security）付费客户。新支持的生态系统包括Shell/Bash、Dockerfiles、Terraform、PHP——恰恰是CodeQL免费版不分析的类型。对于大量使用部署脚本、Dockerfile和Terraform的基础设施仓库，免费扫描等于零覆盖。

开发者Booyaka101推出了免费Action「ghas-free-pack」，利用成熟的开源扫描工具填补这一空缺，并将结果统一成SARIF格式，直接上传到Code Scanning并生成PR评论。

工具工作原理
在workflow中引用：Booyaka101/ghas-free-pack@v1，并授予security-events: write和pull-requests: write权限。它会自动对.sh/.bash运行ShellCheck，对Dockerfile*运行Hadolint，对.tf运行tfsec，对.php运行PHPStan（需手动启用）。所有发现被合并为一个SARIF 2.1.0文档，上传后与CodeQL的显示效果完全一致，同样出现在Security标签页中。

实际捕获示例（来自测试夹具）
- SC2163：export $INPUT导出的是变量名而非值，典型的shell静默bug
- DL3002：最后的USER是root，容器以特权运行
- aws-ec2-no-public-ingress-sgr：CRITICAL级别安全组允许0.0.0.0/0入站
- PHPStan level 5：参数类型错误和未定义变量

使用限制
这是确定性基于规则的扫描器，不复制GitHub的LLM分析。PHPStan需手动启用（enable-phpstan: true），避免默认噪音。由于是Docker action，仅支持Linux runner，首次运行需拉取镜像。SARIF上传需要security-events: write，PR评论需要pull-requests: write，缺失时仍会写job summary但无法发布。

验证可靠性
仓库附带本地测试脚本test/run-local.ps1，构建镜像后对测试夹具运行，断言17项验收标准，包括合并后SARIF通过ajv验证（需使用json.schemastore.org提供的schema）、PR评论包含预期规则、重复运行会PATCH已有评论而非重复发布。MIT许可，可放心使用。

免费工具为那些被挡在付费墙之外的基础设施仓库提供了社区驱动的安全扫描替代方案。

GitHub

#开发者 #工具 #GitHub #CodeScanning #GHAS #ShellCheck #Hadolint #tfsec #PHPStan #SARIF #DevOps
@DevToolboxHub

仅7家大公司招聘页可爬，如何一次检测

测试了42家大型雇主的招聘页面，仅7家可直接爬取。多数企业使用Taleo、Oracle等企业级ATS，不提供公开API。下面介绍如何用一个请求快速判断。

现代ATS（Greenhouse、Lever、Ashby、SmartRecruiters）提供开放API，无需认证。企业级ATS（Taleo、Oracle、Phenom、iCIMS）则依赖会话与JavaScript，无法直接抓取。通过检查招聘页HTML的正则匹配，即可识别ATS类型。
检测ATS的Python代码：import requests, re；SIGNATURES字典包含Greenhouse、Lever、Ashby、SmartRecruiters、Workday、Taleo、Oracle、Phenom、iCIMS的正则；函数detect(careers_url)发送请求并匹配，返回ATS类型。若返回Taleo等，直接放弃。
识别后调用API：Greenhouse可用GET https://boards-api.greenhouse.io/v1/boards/{slug}/jobs，Lever类似。注意Workday的limit不能超过20。
不猜slug，从真实URL读取。作者提供了一个免费的开源爬虫工具，自动检测ATS并归一化数据。

该方法可节省大量试错时间。对所有想爬招聘数据的开发者而言，先检测ATS再动手，事半功倍。

#开发者 #工具 #爬虫 #ATS #Greenhouse #Lever #JobScraping
@DevToolboxHub

双语爬虫数据陷阱：阿拉伯语与英语

爬虫教程通常只假设单语言场景。当面对阿拉伯语/英语双语市场时，会遇到一种永不抛异常的 bug：请求成功、HTML 解析正确，但每个目标字段都为空。以下是构建双语职位数据集时积累的经验。

一个字段全空的典型场景：抓取职位页的「资历级别」和「雇佣类型」，测试正常，生产环境却返回 null。状态码 200，HTML 有效。原因是链接指向了区域子域名（如 ae.example.com），返回阿拉伯语页面，而选择器匹配的是英文标签「Seniority level」「Employment type」，页面显示为「المستوى الوظيفي」和「نوع التوظيف」。修复只需在抓取前将域名规约为主域名：re.sub(r"https://[a-z]{2}\.example\.com/", "https://www.example.com/", url)。通用教训：如果一个字段在所有记录中都为空，先怀疑地区语言问题，再怀疑选择器本身。防御措施：解析后断言关键字段已填充，否则抛异常——一个会崩溃的爬虫比一个默默返回空值的爬虫好得多。

数字陷阱：阿拉伯页面常使用东阿拉伯数字（如 ٢٠٠ 表示 200）。Python 的 int("٢٠٠") 能正确返回 200，"٢٠٠".isdigit() 为 True，re.findall(r"\d+", text) 能匹配到，因为 \d 默认支持 Unicode。但大多数人习惯写 [0-9]+，这在阿拉伯数字页面上会永远返回空列表，让你误以为字段缺失。如果希望输出始终为 ASCII 数字，可以用 str.maketrans 翻译：ARABIC_DIGITS = str.maketrans("٠١٢٣٤٥٦٧٨٩", "0123456789")，再 int(re.sub(r"\D", "", text.translate(ARABIC_DIGITS)))。

关键词匹配：子串匹配在双语数据集中容易出错。例如 "coo" in title 会匹配到「Coordinator」，把项目协调员误判为首席运营官；"partner" in title 会匹配到「Partner Onboarding Specialist」，把入职专员提升为合作伙伴。解决方案：始终使用单词边界正则 re.search(r"\bcoo\b", title)。数据验证：在发布统计数字前，务必打印实际行。示例中，某市场 18% 的职位被标为「高管级」，打印后发现一半是协调员和入职专员，真实比例仅 16%。

机器翻译与编码：为双语数据集添加阿拉伯语标签时，始终保留原始字段（如 title 和 titleArabic 并存），只将翻译用于显示，所有连接、去重和过滤应在源语言字段上进行。编码方面，在所有读写边界显式设置 UTF-8：sys.stdout.reconfigure(encoding="utf-8")，Path(p).read_text(encoding="utf-8")。注意 UTF-8 BOM 可能导致部分 JSON 解析器报错，先检查 BOM 再检查语法。

以上经验来自维护区域招聘网站的爬虫（输出中英文标签），全部踩坑记录在作者的 Apify 页面。

#开发者 #工具 #爬虫 #Python #阿拉伯语 #双语数据 #Unicode #正则表达式 #数据清洗 #工程效率
@DevToolboxHub

数字化失败案例：政策与反馈循环

一位前 NHS 员工在被迫离职后，目睹了团队引入的“新系统”——把原本纸质或类 Excel 的流程搬到屏幕上，但问题依然存在：重复填写、信息重叠、无人应答。作者从工程师视角拆解了这个失败模式，指出其本质是工程中常见的经典错误：把坏流程数字化，得到数字化的坏流程。

文章从几个层面展开：政策即规格说明，软件即实现。当政策要求“提供个性化支持”而软件只提供一个硬编码流程时，实现就与规格矛盾，就像 bug 一样自然产生。系统本身是不可靠的第三方依赖——无文档、无负责人、bus factor 为零，甚至是从美国未经审查引入英国的。可及性不是 UI 问题，而是架构问题：底层模型假设所有人走同一条路径，再漂亮的界面也无法帮助那条路径之外的人。反馈环路被切断：诚实报告问题的人被惩罚，issue tracker 静默，从外部看以为系统稳定，实际上是传感器被关闭了。开源的潜力巨大，但必须与政策同步进化——仅开源实现而不改变反馈文化，只是把故障公之于众。

文章最终提出：真正的问题不是“如何数字化现有流程”，而是“如何构建一个从使用者那里持续学习的系统”。核心是把决策过程本身也变成可观测的，让反馈回路真正闭环。这与技术栈无关——Python、Java 还是纸张，底层价值观一致：透明、问责、共享责任。一个只交付服务的系统是盲目运行的，而一个能学习的系统才值得建造。

#开发者 #工具 #NHS #UK #开源 #反馈循环 #系统架构 #政策 #可观测性
@DevToolboxHub

6个AI网关横向对比：路由、治理、缓存与可观测性

AI网关是位于应用代码与模型提供商之间的单一控制面。没有它，每个服务各自处理提供商密钥、重试、速率限制、缓存和日志；有了它，所有请求穿过同一端点，获得一致的访问规则、配额、成本核算和审计记录。

评估网关应关注：是否整合了多提供商接入、能否限制开销是否通过缓存去重、是否保留持久审计日志、能否在延迟/成本/输出质量变化时了解生产状况。

本次对比覆盖六个产品，分为两大类：基础设施优先型（在现有API管理、K8s或边缘平台上扩展AI能力）和LLM原生型（从模型接入、流量监控入手）。选型取决于你的真实约束是基础设施控制、提供商路由，还是将生产流量与质量度量挂钩。

1. Braintrust Gateway
最适合想将模型路由与追踪/评估整合在同一系统中的团队。提供单一API路由至OpenAI、Anthropic、Google、AWS、Azure、Mistral等。通过指向gateway.braintrust.dev即可接入。关键特性：网关流量默认进入可观测与评估层，无需额外插桩即可追踪输入、输出、延迟和成本；这些跨度可评分、注释、加入数据集、用于CI检查。缓存支持AES-GCM加密并按用户隔离。免费Beta中，Pro $249/月。

2. Portkey
面向需要托管网关捆绑治理、护栏、提示管理与合规控制的企业团队。通用API包含路由、回退、负载均衡、重试、虚拟密钥、日志、追踪、元数据、过滤器和告警。支持确定性护栏与基于LLM的护栏。Free层10K日志请求，付费$49/月起，企业版含SSO、细粒度预算等。

3. LiteLLM
适合有DevOps能力的团队，运行自托管开源网关。Python SDK及Proxy Server支持100+提供商，提供虚拟密钥、预算、团队、负载均衡、RPM/TPM限制、护栏及日志集成（Braintrust、Langfuse等）。免费开源，企业版含SSO和审计日志。

4. Kong AI Gateway
适合已运行Kong的企业，将AI控制能力通过插件嵌入现有API管理栈：通用LLM路由、语义缓存、MCP/A2A网关、RAG注入、护栏等。需部署完整API管理平台，部分插件需付费，无原生评估工作流。30天免费试用。

5. SUSE AI Universal Proxy
面向K8s原生企业，关注MCP服务器治理与代理。开源（Apache 2.0），提供发现、注册、身份认证、成本追踪、日志等功能。更偏向MCP治理层而非通用LLM路由器。需K8s与平台运维能力。

6. Cloudflare AI Gateway
希望边缘缓存、速率限制、使用可见性且无需运维的团队。通过Cloudflare路由AI请求，核心功能全计划免费。可观测性以指标和日志为主，结构化评估需独立系统。部分功能处于Beta或依赖其他Cloudflare订阅。

选型总结
- 基础设施治理是约束 → Kong或SUSE
- 你想拥有代理 → LiteLLM（覆盖最广、免费，但需工程能力）
- 需要治理/护栏/提示管理一体化 → Portkey
- 需要边缘缓存+零运维 → Cloudflare
- 需要路由直接接入评估与发布检查 → Braintrust（唯一将网关流量变为评估输入的选项）

值得注意的差距：五款工具停留在告诉你发生了什么（指标、日志、成本仪表盘），而网关本身就持有最宝贵的评估数据——真实输入、输出、延迟和成本。如果这些数据不能流入数据集、评分器与预发布检查，你仍需重建第二条管道。Braintrust是本次对比中唯一围绕闭环构建的产品，这使其成为推荐首位，而非单个网关特性。

#开发者 #工具 #AIGateway #Braintrust #Portkey #LiteLLM #Kong #SUSE #Cloudflare #LLM #可观测性
@DevToolboxHub