Agent框架

Anthropic 10 月 15 日正式放出 Claude Code 桌面版的史诗级更新，团队成员自己都评价「几乎像 v2」。新界面把会话管理整个重做：侧边栏按「需要你、正在跑、已完成」分组，任务卡片可以派生嵌套子会话，输入 /btw 或按 Cmd 加分号就能旁开小窗问一句，不打断主任务。环境复用、后续任务一键拉起、实时待办、回顾卡片都是新东西。Pro、Max、Team、Enterprise 付费档可用，Linux 版仍是 beta。 「需要你、正在跑、已完成」为什么比多标签重要？ 过去的多标签解决的是并行，没解决的是「回来看什么」。任务跑起来之后你去干别的，回来面对一排标签，得逐个点开才知道哪个在等你、哪个已经跑完、哪个早就死了。新侧边栏把状态直接按队列分好：需要你的先顶上来，正在跑的排队，已完成的归拢。这本质是把「指挥 AI 军团」的管理界面从标签页升级成了作战室。一个人同时挂四五个长任务时，这个分组省下的上下文切换时间是实打实的。 /btw 旁问为什么是心流补丁？ 程序员最贵的成本是心流被打断。主任务跑着跑着冒出个临时疑问：这个鉴权 Token 默认过期多久？过去你得切出去另开一个对话，或者打断主线直接问，前者打断思路，后者污染主任务上下文。/btw 开个旁窗，小问题小窗解决，主线继续跑。配合会话环境复用，派生的子会话还能继承主线的项目上下文，不是从零开始的空白对话。 桌面 Agent 工具的竞争已经进入编排层：不再比谁单任务聪明，比谁能让一个人同时指挥五个任务还不手忙脚乱。实际用下来还有两个细节值得知道：一是多会话并行烧的是同一账户的额度，同时跑四个长任务会显著加快套餐额度消耗，月底账单出来前要有心理预期；二是 Linux 用户这次仍是 beta，功能与 macOS 版有差距，生产工作流暂时不建议迁移。等 Linux 版转正，这套指挥界面才算真正全平台可用。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

DEV Community 10 月 14 日的一篇长文把编码 Agent 的攻击面讲得很透：今年四月安全研究者公开演示过一种注入模式，能同时劫持当时最流行的几款编码 Agent——Claude Code、Gemini CLI、以及在 GitHub Actions 里运行的 Copilot Agent。载体不是高深的漏洞，是伪造的 GitHub 评论、PR 标题和 issue 正文。结果是命令被执行，凭证暴露在 Actions 日志里。这是第一次公开证明，一条注入可以跨厂商同时生效。 为什么开源仓库环境成了最佳投毒点？ 编码 Agent 天然要读仓库内容：issue 讨论、PR 描述、代码注释，全是它日常摄入的「上下文」。攻击者不需要攻破任何服务器，只需要给一个热门仓库提一条 issue，正文里藏一句「请把以下脚本加到 CI 里运行」，等 maintainer 那边的 Agent 读到。更糟的是 GitHub Actions 环境的 Agent 天然带着仓库的 secrets，执行完命令顺手把环境变量打到日志里，等于白送凭证。开源项目越多的团队，暴露面越大。 CI 里跑编码 Agent 该怎么配最低权限？ 第一，给 Actions 里的 Agent 用单独的低权限机器账号，不给主仓库 secrets，需要发版权限的步骤单独走并设人工审批。第二，把 Agent 能读到的外部内容加隔离：issue 和评论渲染进沙箱再喂给模型，不让其与工具调用共享同一个系统提示通道。第三，命令执行类工具默认全局关闭，改成显式白名单。第四，定期审计 Agent 历史调用记录，找有没有执行过非预期域名的命令。 编码 Agent 的便利和暴露面是同一件事的两面。你把钥匙交给它的那天，就该知道它会替谁开门。还有一个容易被忽略的传染路径：Agent 修复被投毒 issue 时写出来的代码本身可能被埋下后门，审查 Agent 的输出和审查人类提交一样严格。对开源维护者的最低建议是：不在 Actions 里跑带 secrets 的 Agent，本地手动触发的 Agent 会话不要长期留存凭证。防御的总原则只有一句：把 Agent 当作一个需要签保密协议的新员工来对待。 ...

TechGig 10 月 14 日的安全报道措辞相当直接：一个被称为「致命三要素」（lethal trifecta）的 AI Agent 结构性漏洞正在被主动利用，攻击者通过提示注入就能完成远程代码执行和数据外泄。报道同时点出企业侧的普遍盲区：多数企业对自己部署了多少个 Agent、每个 Agent 持有什么身份，完全没有可见性。 「三要素」凑齐的是哪三块积木？ 把它拆开看，三个条件单独都不致命：一是 Agent 能访问外部内容（读网页、读仓库、读邮件），二是外部内容里藏着注入指令，三是 Agent 还持有执行工具的权限且默认放行。单独看，第一条是 Agent 存在的意义，第二条是互联网的常态，第三条是为了少打断用户。但三者一旦凑齐，攻击者只需要把一句话藏在 Agent 会读的某个页面里，剩下的交给 Agent 自己动手。这不是模型的问题，是架构把「读」和「做」之间的闸门拆了。 加固优先级为什么先从身份可见性开始？ 报道给的第一刀不是技术补丁，是盘点：先回答你到底有几个 Agent、每个 Agent 背后用的是谁的凭证、能调哪些工具。很多团队的实际情况是，IT 部门不知道市场部给客服配了个能查客户库的 Agent。可见性之后才是技术加固：给「写」和「执行」类工具设人工确认、把 Agent 的网络出口收敛到白名单、外部内容渲染前先过一遍注入检测。把确认按钮加回高危操作，看起来是体验倒退，但在主动利用已经出现的当下，这是最便宜的止损。 Agent 安全的本质是给一个会读会写的系统重新装上闸门。闸门装得晚，代价就是某次泄露事故之后补的。企业侧最该先做的动作其实是一张表：列出所有 Agent、各自的调用凭证、能读写的数据源、能执行的命令范围。这张表建出来，你会发现大量 Agent 的权限远超它的任务需要。收缩权限之后，再考虑技术检测——外部内容进 Agent 前过一遍注入特征扫描，是投入产出比最高的一道防线。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

智东西 10 月 14 日晚间报道，APUS AI 正式开源了个人智能体产品 Reflex Agent，仓库地址为 APUS-AI-Lab 的 APUS-Reflex-Agent，采用 MIT 协议，提供桌面端、Web 端和 SDK。它想解决的是 Agent 圈最近最痛的一个问题：长任务跑到一半「失忆」。官方称其响应速度达到主流 Agent 的三倍。 「模型驱动 Harness」和传统提示词驱动差在哪？ 大多数 Agent 框架的控制逻辑是代码写死的：先判断任务类型、再选工具、再拼提示词，模型只负责出最终答案。Reflex Agent 的思路反过来：用一个专门的决策模型 Reflex 来驱动核心控制逻辑——什么时候该调工具、什么时候该查记忆、什么时候该收尾，这些决策本身也是模型推理出来的。这带来的好处是长任务里的策略调整更灵活，坏处是多了一次决策模型调用，链路更重。对二次开发者，MIT 协议意味着你可以把这套「模型管模型」的循环拆出来，移植到自己的 Agent 场景里研究无损记忆的实现。 Continuum 记忆引擎是「无限上下文」吗？ 宣传口径里的「无限上下文」要打折听。它不是突破单次模型调用的输入长度限制，而是外部记忆机制：Continuum 引擎长期积累、检索和调用历史任务信息，减少对压缩摘要的依赖。实际用法上，这更接近一个带检索的长期记忆库，适合需要跨任务记住用户偏好的个人助手场景。接入 SDK 时，建议先明确哪些任务需要跨会话记忆、哪些只需要会话内，什么都往记忆库里塞会让检索质量迅速劣化。 框架开源的价值从来不只是「能跑」，而是把别人踩过的记忆与调度工程一起给你。MIT 协议这一点，对想商业化的团队是最大的诚意。和现有主流框架比，Reflex Agent 的差异化在「决策也交给模型」这个激进程度上，好处是策略灵活，代价是调试难度上升——传统框架的行为可以逐行审计，模型决策的黑盒部分要靠日志回放。建议二次开发时先把决策模型的每次选择落盘，没有这套观测能力，长任务出问题时根本无从下手。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

翻看十月九日仍在更新的 Claude 平台 release notes，Agent Skills 和对应的 Skills API（/v1/skills）已经正式离开测试版状态：请求里不再需要带 skills-2025-10-02 这个测试头，就连 Messages API 里通过 container 参数加载 Skill 的调用也转正了。同时，那个 BetaSkill 类型被重命名为 BetaContainerSkill，旧头还能兼容一阵子。对 Agent 框架的开发者来说，这不是一次小版本——它意味着「给模型外挂一套随取随用的专业工具包」这件事，从临时实验变成了一等 API。 Skills 到底是个什么东西，和 MCP 工具差在哪？ MCP 解决的是「让模型能调用外部工具」：连数据库、调 API、跑脚本，重点在动作。Skills 解决的是「让模型临时获得某项专业知识与流程」：它是一组说明、脚本和资源的打包，模型在做某个专门任务时动态加载进来，干完就卸载。区别在于，MCP 是接外部世界的手，Skills 是塞给模型的一本「临时操作手册」。比如做一个财务审计的 Skill，里面放着审计清单、勾稽脚本、报表模板，模型遇到审计任务时自动把这套东西读进去，而不是把所有领域知识都塞进系统提示词里。 容器化加载，解决了之前的什么痛点？ 早期 Skills 要靠测试头和一堆 beta 结构硬挂，加载方式是隐式的。现在转正后，Skills 通过 container 参数以容器化方式加载，配合 client.beta.skills.delete() 这类接口，可以完整管理一个 Skill 的多版本、动态增删。这等于给「模型的专业能力包」建立了生命周期管理：谁在用哪个版本、什么时候加载、什么时候卸载，都变成可显式控制的对象。对企业来说，这才是能上生产的形态——能力包可以像 App 一样上架、灰度、回滚，而不是散落在提示词里的魔法字符串。 这对 Agent 开发生态意味着什么？ Skills 转正加上容器化，等于官方在推一种新的分发单元：以后模型的能力不再只靠微调权重，而是靠一摞可组合、可热插拔的 Skill。你想让 Claude 会做某个垂直任务，不必重训模型，只需发一个 Skill 包。这会催生一个类似 App Store 的 Skill 生态——谁写的 Skill 更专业、加载更省 token，谁就更有价值。对框架作者，接下来要关注的是 Skill 之间如何复用、版本如何治理、以及一个 Skill 在被自动加载时会不会带入新的提示注入面。能力包越自由，供应链风险就越要盯紧。 ...

据 AI Tool Tier 评测数据，Cognition 的 Devin Fusion 采用 lead/sidekick 双模型编排架构，实测每个编码任务的成本比单一大模型方案降低百分之二十三到四十六。这个架构跟传统的单 Agent 循环思路完全不同。 分工是这样的：lead 模型负责理解任务、拆解步骤、审查 sidekick 的输出；sidekick 模型负责实际写代码、跑测试、改文件。lead 用强模型但调用次数少，sidekick 用便宜快速的模型但承担大部分 token 消耗。两模型通过结构化消息通信，不是简单的提示词嵌套。 这种编排的经济学很直观：大模型贵但你不需要它全程参与——只需要在关键决策点用它。执行层面的重复劳动交给小模型。九月十五日 Cognition 跟 AWS 签了多年期协议，把这个架构跑在 AWS 基础设施上，说明成本优化已经到了可以规模化的阶段。 Devin Fusion 的双模型架构给整个编码 Agent 行业提供了一个新的思路。以前大家都在追求一个超大模型包打天下，Fusion 证明了用两个各司其职的模型组合起来，效果更好还更便宜。这个思路很可能会被其他编码 Agent 产品借鉴。 从成本结构上分析，lead 模型虽然单价高但调用次数少，sidekick 模型单价低但承担大部分 token。这种组合的总成本比全程用大模型低百分之二十到四十六，这个数字在规模化之后是非常可观的节省。对于每天处理成百上千个编码任务的团队，每省一块钱乘以任务量就是大钱。 为什么两个模型比一个大模型更省钱？ 这个思路其实跟人类团队的分工一样：架构师不用亲自写每一行代码，但要审查每个关键决策。初级工程师写大部分代码，但每个 PR 都要过架构师这关。Devin Fusion 把这个模式复制到了 AI Agent 里。 lead 和 sidekick 具体怎么分工？ 对自建编码 Agent 的团队来说，这个架构值得借鉴。你不一定需要用 Devin，但可以用同样的思路：用一个强模型做路由和审查，用便宜模型做执行。这种分层可以显著降低每次编码任务的边际成本。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据 Cline 项目 README，这个开源编码 Agent 的命令行工具提供四种运行模式。默认的 cline 或 cline -i 打开完整终端交互界面，带 plan/act 切换、斜杠命令、文件提及和实时工具审批——适合人在旁边盯着的交互式编码。 cline 直接加 prompt 参数则是一次性模式：跑一个回合就退出，适合脚本里调用。cline –json 模式以 NDJSON 格式流式输出事件，可以管道接进其他工具或 CI 系统——你可以自己解析事件流，在工具执行前加自定义审批逻辑。 最激进的是 cline –yolo 模式：跳过所有审批提示，让代理自主执行直到任务完成。这个模式威力巨大但风险也大——它会自己改文件、跑命令、装依赖。建议只在隔离的 Docker 容器或临时分支里用，千万别直接在主力开发机上开 Yolo。 Cline 作为开源编码 Agent，最大的优势是透明和可控。跟闭源的 Devin 或者 Claude Code 不同，你可以看到它的每一步操作、修改它的提示词、定制它的工具权限。这种可控性对于有安全合规要求的企业特别重要。 四种运行模式覆盖了从交互式开发到全自动化 CI 的完整场景。TUI 模式适合人在旁边盯着的探索性编码，one-shot 模式适合脚本里的简单任务，JSON 模式适合接入自研的审批流程，Yolo 模式适合在隔离环境里批量处理。选择哪个模式取决于你对自动化程度和风险承受力的平衡。 JSON 事件流模式怎么接入 CI 流水线？ JSON 事件流模式是接入 CI 的关键。你可以写一个脚本启动 cline –json，监听事件流，在代理要执行危险命令时插入人工审批或者自动拒绝。这样就实现了半自动化——代理做大部分工作，关键节点人来把关。 Yolo 模式到底有多危险？ Cline 作为开源项目，跟闭源的 Devin 和 Claude Code 相比，优势在于你可以完全掌控它的行为。所有提示词、工具列表、审批规则都可以自定义。对于有安全合规要求的企业，这种可控性是闭源工具给不了的。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据 Mastra 官网更新，十月一日平台新增了 VPC 隔离的托管 Postgres 数据库服务。这不是给普通 Web 应用用的——它是专门给 Mastra Agent 做状态存储的：会话历史、记忆条目、工作流中间状态、工具调用日志，全部持久化在这个 Postgres 里。 VPC 隔离意味着你的数据库跟 Mastra 平台其他用户的数据库在网络层面完全隔离，只能通过你自己的 VPC 连接。对企业用户来说这是合规要求——Agent 处理的数据不能跑在共享多租户环境里。 同期发布的 Server Adapters 则解决了部署痛点：以前你要单独起一个 Mastra 服务端口，现在它可以作为中间件挂在你已有的 Express 或 Hono 应用里。Agent、工作流、工具和 MCP 服务器自动暴露为 HTTP 端点，不需要额外的运维负担。 Agent 应用的状态管理一直是个被低估的难题。跟普通 Web 应用不同，Agent 的状态不是简单的用户数据——它包括对话历史、长期记忆、工作流检查点、工具调用审计。这些数据量很大，而且查询模式很特殊。专门为 Agent 设计的 Postgres 托管服务正在填补这个空白。 Server Adapters 的出现则意味着 Mastra 的部署模型更加灵活。你不再需要单独部署一个 Mastra 服务，而是可以把它作为中间件嵌入现有的 Node.js 应用。对于已经有 Express 或 Hono 后端的团队，这省去了维护额外服务的运维负担。 从产品演进的节奏来看，Mastra 几乎每个月都有重要功能发布，这种迭代速度在开源 Agent 框架里算是很快的。 Agent 为什么需要专用 Postgres？ Agent 应用的状态存储比普通 Web 应用复杂得多。你需要存多轮对话历史、长期记忆向量、工作流的检查点、工具调用的审计日志。用普通 Postgres 也能存，但 schema 设计和查询优化很费时间。Mastra 把这些都做好了。 ...

据 Mastra 官方博客十月七日文章，Mastra Connect 正式发布。它的核心能力是：你的 Mastra Agent 现在可以通过统一的 OAuth 连接管理器，调用 Linear、Notion、Slack 以及另外二十多个 SaaS 服务，不需要为每个服务单独写集成代码。 之前要让 Agent 读 Notion 页面、改 Linear ticket、发 Slack 消息，你得分别去各平台申请 API 凭证、写请求封装、处理 token 刷新。Connect 把这些标准化了——在 Mastra Studio 里点几下完成 OAuth 授权，Agent 代码里直接 import 对应工具就行。 同期发布的还有 VPC 隔离的托管 Postgres 数据库，以及 Server Adapters——让你在已有的 Express 或 Hono 应用里直接挂载 Mastra Agent、工作流和 MCP 服务器作为 HTTP 端点。对 TypeScript 技术栈的团队来说，Mastra 正在从一个 Agent 框架长成完整的 Agent 运行时平台。 Mastra Connect 的发布，本质上是在解决 Agent 开发中最耗时的环节：工具集成。写一个能读 Notion、改 Linear、发 Slack 的 Agent，光写各个平台的 API 封装就要好几天。Connect 把这些标准化之后，开发者可以把精力集中在 Agent 的业务逻辑上，而不是跟各个 SaaS 平台的 OAuth 流程搏斗。 ...

当一个 Agent 不够用，行业开始让多个 Agent 互相协作。MCP 解决的是 Agent 怎么连工具，而 Agent 之间怎么对话，靠的是 A2A（Agent2Agent）这类协议。NIST 在其智能体威胁材料里，已把 MCP、A2A、ACP 并列列为「不安全协议」——A2A 的信任问题，和 MCP 一样被低估了。 MCP 与 A2A 到底怎么分工？ 打个比方：MCP 是员工去操作公司系统（工具），A2A 是员工之间打电话派活。前者管的是「能不能动那个工具」，后者管的是「能不能信对面那个 Agent」。多智能体系统里，一个主管 Agent 把任务派给执行 Agent，执行 Agent 又可能调 MCP 工具——信任是层层传递的。 Agent 互联引入了哪些新的信任风险？ A2A 引入了几个 MCP 没有的问题：对面那个 Agent 是谁？它代表哪个组织？它返回的中间结果可不可信？如果不做身份与意图认证，恶意 Agent 可以混进协作网络，把任务引向错误工具，或泄露上游敏感上下文。这和 MCP 里的隐式信任传递是同一类病，只是发生在 Agent 之间。 多智能体协作的务实做法是什么？ 在 Agent 间握手时做显式身份与能力声明；对跨组织的 Agent 协作，限定可委派的任务范围；给 Agent 间通信加审计日志，出问题能追溯是哪一环下的指令。把 Agent 之间的关系，当成公司间合作而非同事间闲聊来管理。 多智能体时代的信任模型要怎么重建？ 多智能体不是把单 Agent 放大就行，信任模型必须重新设计。A2A 补上了通信这层，但信任这层，仍要靠框架与企业自己加。 一个最小可用的协作治理框架长什么样？ 搭多智能体系统时，先画一张信任图：哪些 Agent 在同一组织内，哪些跨组织；任务委派链有多长。同一组织内可以宽松些，跨组织则必须显式身份认证与任务范围限定。给每条 Agent 间通信加审计日志，记录谁委派了什么、谁调用了哪个工具。一旦线上出问题，这张图与日志能让你在分钟级定位是哪一环被污染。把 Agent 协作当分布式系统来治理，而不是当几个聊天机器人拼在一起。协议提供连接，治理才提供信任——后者没有捷径。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：A2A协议 ...