Agent/框架

当一个 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多智能体

OpenAI 在九月完成了两次关键发布：9 月 10 日 Agents API 公测——一次 API 调用就能构建云端智能体，带 OpenAI 托管沙箱、可跨长会话保持状态；9 月 29 日 DevDay 2026 又推出 dots：由 GPT-6 Astra 驱动、各自拥有一台云端计算机、全天候在线的智能体。两天后还与 AWS 合作推出 Bedrock 托管智能体。这个组合标志着智能体框架的范式正在从「编排 SDK」转向「托管云电脑」。 旧范式：你写循环，你管环境 LangGraph 那一代框架的思路是：开发者自己写工具调用循环、自己管上下文、自己起沙箱、自己处理失败重试。灵活，但工程负担全在开发者身上——安全、隔离、长会话状态，都要自己兜底。 新范式：一个 API 调用，环境是托管的 Agents API 的卖点很直接：选一个托管沙箱环境，一次调用就把智能体跑起来，跨长会话持续工作。dots 更进一步：它不是一个被调用一次的函数，而是一个常驻的、有自己云电脑的「数字员工」，你给它目标与可自主执行的边界，它持续推进。OpenAI 还设想多个 dots 组队协作。 配套的还有 Decisions API：把 GPT-6 Luna 的智能限定在用户预设的有限选项里做实时决策，用于内容分类与路由。 对开发者的含义 这不是说编排框架过时了——复杂工作流仍需要显式编排。但对于「给一个目标、让它在云端把活干完」这一类任务，托管沙箱把安全隔离、环境快照、长会话状态这些最难的部分收走了。你要做的，是把权限边界划清楚：它能动什么、不能动什么，而不是从零搭一套执行环境。 判断 OpenAI 把智能体的竞争点从「谁的框架图好看」拉到「谁的云电脑又安全又能干活」。框架的下一站，是基础设施。 对企业用户，真正要想清楚的是权限边界。托管云电脑意味着智能体在厂商的环境里连续运行、代你操作各类应用，一旦边界划得太宽，它自主犯错的代价会被放大。越是常驻型智能体，越需要在部署之初就写清楚它能动哪些系统、花多少钱、什么时候必须停下来问人。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Agents API dots

GPT-6 把「智能界面面向所有人」推出来之后，前端工程师的工作量明显变了：不再是渲染静态页面，而是要接住一个一边想一边输出、中途还要调工具的智能体。Vercel AI SDK 就是为这个场景准备的——它在 Next.js 里用几个钩子，把流式文本、工具调用、消息管理都封好了。 两个核心钩子 useChat 是主力：给它一个后端路由，它负责发消息、接收流式 token、逐字渲染到界面。模型输出不是等好了一次性显示，而是像 ChatGPT 那样一个字一个字蹦出来——这个体验过去要自己处理 SSE 流，现在一行钩子搞定。 useToolExecution（或在后端用 streamText 的工具配置）处理「模型要调工具」这一步：前端能知道模型正在执行哪个工具、拿到什么结果、再接着生成。做「智能体查了数据库 → 把结果画成表 → 再写一段解读」这种界面，就靠它。 后端其实很薄 Next.js 的 Route Handler 里，用 streamText({ model, messages, tools }) 把请求转发给任意 OpenAI 兼容接口，返回流。前端只管渲染，业务逻辑在后端。切模型时只改后端一行。 判断 智能界面时代，前端的护城河从「排版」挪到了「如何优雅地展示一个不确定过程」——流式输出、工具进度、错误回退，这些是新产品的基本盘。Vercel AI SDK 把这些脏活收进钩子，让你把精力放在「这个智能体该长什么样」，而不是流解析。GPT-6 给了界面的脑子，这套工具给它配脸。 补一个工程细节：流式输出虽然体验好，但调试变难——你没法一眼看到完整响应。开发期可以临时关掉流式，让它一次性返回，方便对照日志；上线再打开。另外，工具调用中间态要给用户可见的反馈（「正在查询订单…」），别让用户盯着空白界面以为卡住了，这是智能界面最容易被吐槽的细节。 智能界面的体验细节，往往就藏在流式渲染和中间态反馈这些容易被忽略的地方。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：AI前端

RAG 项目做到后面，往往不是「检索一次然后生成」这么简单——要先判断问题类型，事实类走向量检索，计算类走代码工具，拿不准的再走多路召回，最后汇总。用一串 if/else 加函数调用写，三个分支之后就没人敢改了。LlamaIndex 的 Workflows 模块就是给这种复杂度准备的：它把流程拆成「事件」在节点间流动，每个节点是一个被装饰器标记的异步函数。 心智模型 不用记太多，抓住两个概念： Event（事件）：在节点之间传的数据对象，比如 QueryReceived、RetrievalDone、ResponseReady； Step（步骤）：一个异步函数，用 @step 标记，声明它监听哪些事件、又发出哪些事件。 框架帮你做的是并发调度：多个步骤可以同时跑，事件到了就触发。比起手写 asyncio.gather 加回调，这种声明式写法让流程拓扑一眼看清。 一个多分支问答的骨架 @step async def route(self, ev: QueryReceived) -> Union[RetrieveFactual, RunCalculator]: kind = await classify(ev.query) if kind == 'fact': return RetrieveFactual(query=ev.query) return RunCalculator(query=ev.query) 检索和计算两个步骤并行监听各自事件，跑完都发出 ContextReady，再由汇总步骤合并成最终回答。新增分支，就是加一个事件类和一个步骤函数，不用动老代码。 判断 事件驱动框架的好处在「可观测」：每个事件是一条明确的边界，配合日志你能知道流程卡在哪一步。对那些已经从单轮 RAG 长出来、但还没复杂到要上重型编排引擎的团队，Workflows 是一个比 LangGraph 更轻的中间档——它不抢你的控制权，只把流程显式化。 补一个心智提醒：事件驱动不是银弹。流程只有两三个节点时，写 Workflows 反而比直接 async 更啰嗦。它的甜区是「四五个分支、要并发、要可观测」的中等复杂度。如果你只是线性检索加生成，别为了用框架而用框架——直接函数调用最清楚，也好调试。 框架是手段，把流程画清楚才是目的。别让工具本身，变成新的复杂度来源；分支少的时候，最朴素的函数调用，反而是最不容易出错、最好调试的选择。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：LlamaIndex

9 月底以来，各家大厂都在补「开发智能体」的官方工具链。谷歌这边对应的是 ADK（Agent Development Kit）：一套 Python 框架，配合云上的 Agent Engine，可以把本地调试好的智能体直接托管成一个带日志、可扩展的线上服务。相比自己在服务器上拼 Flask 加队列，这套组合把「造完 → 上线」的工程摩擦压到最低。 一条最小链路 本地用 pip install google-adk 装套件，然后按它的原语组织代码：一个 Agent 带 instruction，挂上 tools，可以嵌套子 Agent。本地调试时用 adk run 你的agent 在命令行里对话，快速改提示词。 调通之后，用 adk deploy agent_engine 把它推到谷歌云的 Agent Engine，平台会分配一个 HTTP 端点，自动带上会话持久化与调用日志。后续要改提示词，本地改完再部署，不用碰服务器。 两个设计要点 工具即函数：ADK 里一个 Python 函数加装饰器就是一个工具，模型自动获得调用它的能力。把读数据库、调内部 API 的动作封装成函数，比手写 JSON Schema 直观得多。 可观测先于优化：部署后先在 Agent Engine 控制台看每一步的轨迹——模型调了哪个工具、花了多少 token、在哪一步卡住。没有轨迹就谈优化，都是猜。 判断 框架之争的下半场，比的不是谁的抽象更优雅，而是谁把「本地 → 托管 → 观测」的链路做顺。ADK 加 Agent Engine 的组合，对已经在谷歌云上的团队是顺理成章的选择；跨云团队则可以把它当一个参照系，去衡量其他框架的托管体验。 补一个省钱细节：本地调试时用便宜模型快速迭代，部署到 Agent Engine 后再切到 Gemini 旗舰模型做正式推理。因为代码与模型解耦，这个切换只改一行配置，不用重写逻辑。另外，把成本敏感的工具调用加上缓存——读同一份配置文件，别让 Agent 每次都重复读、重复计费。 ...

当团队里有人说「我想要一个能读表格、按规则出结论的小助手」，直接写代码往往是杀鸡用牛刀。Dify 这类开源编排平台的价值，就是把模型调用、知识库、条件分支、人工节点拖成一张图，产品经理也能看懂。在 Manus 这类通用 Agent 越来越强的同时，垂直小场景反而更适合用「可控的工作流」而非「自由的 Agent」。 最短部署路径 官方仓库自带 docker-compose。在一台有 8GB 内存以上的机器上： git clone https://github.com/langgenius/dify.git，进入 docker 目录； 复制 .env.example 为 .env，按需改对外端口与密钥； docker compose up -d，等所有容器起来后访问 http://localhost/install 初始化管理员账号。 接模型与跑通第一个流 进控制台后，在「模型供应商」里填 OpenAI 兼容接口的 base_url 与 key——DeepSeek、智谱、自建网关都能接。然后建一个「工作流」： 开始节点收一个文本输入（待审批的报销描述）； 接一个 LLM 节点，提示词让它按「金额／事由／是否超标」三栏输出； 再接一个条件分支，金额超阈值走「转人工」，否则走「通过」。 Dify 会自动把这个流暴露成一个 API 端点，内网系统直接 POST 调用。 什么时候该用，什么时候别用 工作流适合路径确定、要求可复现的场景：审批摘要、合同初筛、客服分流。它不适合开放式任务——那种要让模型自己决定下一步做什么的，交给 Agent 框架。把 Dify 当「可控的自动化管道」，而不是「万能机器人」，它才会好用。 补一个团队协作的细节：Dify 的应用可以一键发布成网页或 API，产品同学在网页上自己调提示词和知识库，工程师只负责接后端接口。这种分工比「所有改动都要开发提 PR」快得多。上线前记得打开它的调用日志，看每个节点的耗时，慢的那一步往往是被忽略的外部接口，而不是模型本身。 把 Dify 用成团队的「自动化管道车间」，而不是一个人玩的玩具，它的价值才真正释放出来，产品和工程各就其位。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Dify实战