Agent/框架

翻看十月九日仍在更新的 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协议 ...

OpenAI 在 Agents API 公测后，把它的多智能体协作范式提炼进了 Agents SDK：两个核心概念——交接（handoffs）与护栏（guardrails）。对想做「主助手把不同子任务交给专家智能体」的团队，这是一套比从零编排更轻的范式。 handoff 到底解决什么问题？ 想象一个客服主助手：用户问技术问题，它不该自己硬答，而是交接给技术专家；问退款，交给财务专家。交接不是普通的函数调用，而是把对话控制权整体转移，接收方带着完整上下文继续。SDK 负责交接点的状态传递，你不用手动复制历史消息。 guardrail 为什么要做前置拦截？ 在模型动手之前，先用一个轻量检查过一遍输入或输出：用户想让你把钱转到陌生账户？直接拦下，根本不让主助手去规划。这比事后纠正便宜得多——一次拦截省掉后面十几轮错误调用。 主从结构该怎么搭？ 主助手注册两个交接目标：技术、财务，配一个护栏检查是否涉及高风险操作。用户进来，护栏先过一遍；安全的话，主助手判断意图，需要时交接给对应专家；专家完成后结果回到主助手统一回复。整个结构比你想象的短，因为大部分状态管理 SDK 已经替你做了。 多角色交接有哪两个坑？ 交接太多会让对话像踢皮球——用户在专家之间被来回转。设一个最多交接两次的上限，超了就强制主助手收尾。护栏规则写太死会误杀正常请求，上线前用一批真实对话跑一遍拦截率，把误杀调到可接受范围。 第一天该怎么快速上手？ 这套原语足够简单，建议第一天就别纠结最佳实践，先搭一个主助手加两个专家跑通完整对话，再回头看交接点顺不顺、护栏误不误杀。框架替你省的是样板代码，省不了你对业务流程的思考——真正要磨的还是那几个交接触发条件写得准不准。 这套原语够不够撑起你的业务？ OpenAI Agents SDK 把多智能体协作压缩成交接加护栏两个原语，上手成本低。对大多数「一个入口、按意图分流专家」的业务，这套范式足够用了——先用交接跑通主从结构，再考虑要不要上更重的编排框架。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：AgentsSDK交接

大模型落地企业，很多卡在语言栈上：大量老系统是 .NET 写的，硬塞一个 Python 智能体进去运维很痛。微软的 Semantic Kernel 就是给 .NET 团队准备的，它也有 Python 与 Java 版本：让模型像调用插件一样调用你现有的企业 API。 Semantic Kernel 插件到底是什么？ 写一个普通的 C# 函数，加一个特性标注，Semantic Kernel 自动把它注册成模型可调用的工具：函数名、参数、描述都变成模型能懂的 schema。你已有的查询订单、查库存、提交审批的接口，包一层就能让模型用，不用推倒重来。 一个最小插件该怎么写？ 定义一个按订单号查询的函数，配上清晰的描述——根据订单号查询物流状态，订单号格式为若干位数字。内核把它注册进上下文，用户自然语言问「帮我查下这个订单到哪了」，模型自己决定调用这个函数并填对参数。关键在于描述写得清不清楚，直接决定模型会不会用。 企业落地有哪两个独特优势？ 一是和现有 .NET 身份、日志、依赖注入体系无缝，不用新造一套。二是插件可以加权限与审计：谁、什么时候、调了哪个业务接口，天然可记。这对要过合规的企业很重要。 自动兜底有什么隐患？ 模型是否调用插件，高度依赖你写的描述好不好。描述含糊，比如只写「查订单」，模型会乱用或干脆不用。把什么时候该调、参数什么格式、返回什么写清楚，插件命中率才上得去。 提示函数怎么参与整体编排？ 除了插件，Semantic Kernel 还有个常被忽略的能力：把一段提示词也封装成可被内核调度的函数。这样你可以把「理解意图」「生成回复」都做成插件式单元，让内核按计划串起来。对 .NET 老团队，这意味着不用引入新的编排语言，用你已有的工程习惯就能把一条业务流程拆成可组合的函数链，学习成本远低于换技术栈。 .NET 团队为什么更该选它？ 对 .NET 技术栈的企业，Semantic Kernel 是比硬上 Python 框架更顺的路径。它不追求花哨的多智能体，而是稳稳地把模型接进你已有的业务系统——这恰恰是大多数企业真正需要的。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：SemanticKernel插件

做智能体最烦的一类错：模型调用工具时返回了格式不对的 JSON，你的解析器当场崩。Pydantic AI 的思路是把 Pydantic 数据模型直接当工具描述，让类型系统替你兜住这件事。 类型安全的工具该怎么写？ 定义工具时，参数用一个 Pydantic Model 描述，框架自动把它转成模型能懂的 schema，并在返回时用同一个 Model 解析、校验。对不上就报错重试，而不是把脏数据塞进你的业务代码。这和手写 JSON Schema、再手写解析是两种可靠度——前者类型一致，后者全靠人肉同步。 一个查订单工具长什么样？ 比如做查订单工具：定义一个订单查询模型，含订单号、日期范围，把它注册成工具。模型返回后，框架直接给你一个类型安全的对象，你在代码里可以放心访问字段，不用写一堆异常处理去防半截 JSON。 它和编排框架怎么分工？ Pydantic AI 偏「单智能体加强类型工具」，不做大而全的多智能体编排。它最适合那种「一个智能体要调一堆结构化工具、且输出必须进业务库」的场景——比如自动查数据、填表、发工单。 自动兜底有什么隐患？ 强类型会让工具描述变长，因为每个字段都要解释清楚。提示词里把每个字段的取值范围写明白，模型才不会瞎填。另外，复杂嵌套模型别设计得太深，模型填深层结构时出错率会上升，能拍平就拍平。 它和原生 JSON 模式差在哪？ 很多模型本身提供结构化输出或 JSON 模式，为什么还要 Pydantic AI？区别在于：原生模式只保证语法合法，不保证语义对——字段可以是格式正确但内容荒谬的字符串。Pydantic 的价值在运行时校验后还能把错误结构化地喂回给模型，让它自己修正，而不是你接住一个解析异常后干瞪眼。对要写库的场景，这层二次校验值得多花一点调用成本。 什么场景必须上类型安全？ 如果你的智能体输出要进数据库、要被下游程序消费，类型安全就不是洁癖，是必需。Pydantic AI 用你已经熟悉的 Pydantic 语法把这件事解决了——少写一堆解析胶水，多一层运行时校验。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：PydanticAI

做多智能体，很多人第一反应是 LangGraph 或 CrewAI。但微软 AutoGen 在 v0.4 重写后走了一条不同的路：事件驱动、异步消息、actor 式的智能体节点。理解它的抽象，对你设计复杂协作流程很有帮助。 AutoGen v0.4 的抽象和 CrewAI 差在哪？ CrewAI 偏「角色分工」：定义几个角色，给个流程顺序。AutoGen v0.4 偏「消息总线」：每个智能体是一个异步 actor，通过结构化消息通信，谁下一步发言由事件和规则决定。它更适合「多个自主进程互相发消息」，而不是「一条流水线顺序执行」。 第一个多智能体怎么搭起来？ 起一个团队：一个组织者负责拆任务，两个执行者并行干活，一个审核者汇总。关键不是把它们串成直线，而是定义好「什么消息触发哪个智能体」。组织者发出任务已拆分事件后，两个执行者各自监听并开工，完成后发回结果就绪，审核者等齐了再汇总。你会发现这套写法天然适合并行，而不是被迫在单线程里排队。 什么场景才该选 AutoGen？ 如果你的协作是「一个主管派活、几个工人并行、最后汇总」这种天然异步结构，AutoGen v0.4 的事件模型写起来很顺。如果是严格的有向无环流水线、节点间状态明确传递，别的编排框架可能更直观。 自动兜底有什么隐患？ 事件驱动意味着调试变难：报错不再是「第几步崩了」，而是「哪个事件没被谁接住」。第一天就要把消息流打日志，否则出了问题你只能在事件队列里盲人摸象。 中间状态该存在哪才安全？ 事件驱动跑起来后，中间状态很容易散落在各个 actor 内存里，进程一重启就全丢。重要的任务进度要落到外部存储，让每个 actor 重启后能从持久化状态恢复。这件事在演示阶段看不出必要，一旦你让它跑过夜任务，就会庆幸早做了——否则半夜任务崩了，第二天只能从头再来。 这套事件范式帮你想清什么？ 多智能体框架没有银弹，只有范式匹配。把 AutoGen v0.4 当成异步消息式协作的样本跑一遍，你对「智能体之间到底怎么协作」的理解会上一个台阶——哪怕最后你仍用别的框架。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：AutoGen多智能体