今年最常被问到的问题已经从"Agent 是什么"变成了"我做的 Agent 为什么不敢上线"。
这个问题值得认真答。因为 Demo 和生产环境之间隔着的，不是模型能力，而是一整套工程问题。这篇不列框架清单，也不聊概念之争，只讲我在实际项目里反复遇到的那些事。
一、先校准一下：什么才算 Agent
有个流传很广的公式：
AI Agent = LLM + 规划（Planning）+ 记忆（Memory）+ 工具（Tools）
四个部分各司其职：
| 组件 | 作用 | 缺了会怎样 |
|---|---|---|
| LLM | 理解任务、推理、决定下一步 | 就是个普通程序 |
| 规划 | 把目标拆成步骤，处理分支和回溯 | 只会走直线，一遇到意外就停 |
| 记忆 | 短期上下文 + 长期偏好与历史 | 聊三轮就忘了最初要干嘛 |
| 工具 | 查数据库、调 API、读写文件、发消息 | 只能说，不能做 |
但真正的分水岭不在组件齐不齐，而在于它是不是一个闭环 ：执行一步 → 拿到环境反馈 → 据此调整下一步 → 直到完成或主动终止。
判断方法很土：把上一步的执行结果改掉，看它下一步会不会跟着变。不会变，那你做的就是一条套了 LLM 壳的固定流水线。流水线也有价值，但别叫它 Agent，也别指望它有 Agent 的适应性。
二、Demo 到生产，五道坎
坎一：上下文是漏斗，不是水箱
新手最常见的直觉是"信息给得越多，答得越准"。实际完全相反。
上下文窗口再大，模型的有效注意力也是被稀释的。把公司制度、产品手册、几千条历史对话全塞进去，真正相关的那几条信息反而被淹没，这就是典型的"上下文腐烂"（context rot）。
工程上的解法不是等更大窗口，而是检索 + 裁剪：
- 长资料先切块、向量化，存进向量库，每轮只按相关度取回 Top-K
- 工具返回的 JSON 别原样塞回去，抽成几行摘要
- 早期轮次里已经没用的信息，主动压缩或丢弃
一句话：上下文是稀缺资源，要像管内存一样管它。
坎二：工具不是越多越好
给 Agent 挂 50 个工具，工具选择本身就是主要错误来源。模型要在 50 个选项里挑一个，选错的概率随数量上升，而且模型变强也救不回来多少。
三条比较实在的经验：
- 先用 2--3 个工具跑通主链路，别上来就铺开
- description 写清边界，尤其是"什么情况下不要用这个工具"------多数人只写"能做什么"，漏了"不该做什么"
- 相似工具合并 ，能用一个
query(type=...)解决的，别拆成三个工具
还有一点：工具的参数设计要面向模型，不是面向人。参数越少、类型越简单、枚举值越明确，调用成功率越高。
坎三：没有状态机，就没有可控性
完全靠模型自由发挥的 Agent，跑过十轮以上必然漂移：重复执行、跳过关键步骤、在子目标里打转。
生产系统的做法是把流程做成状态机 / DAG：
- 关键节点由代码定义，模型只在节点内部做判断
- 节点间跳转有条件、有超时、有重试上限
- 不可逆操作（付款、删除、对外发送）必须过人工确认节点
这大概是 Demo 和生产之间最大的一次心态转变：**你不是在设计一个聪明的对话，你是在设计一个有 AI 参与的流程。** 前者追求自由度高，后者追求失败可预测。
顺带一提，这也是为什么 LangGraph 这类以图为核心的框架在生产里比纯链式调用更受欢迎------它逼你把状态显式化。
坎四：不可观测，等于没上线
Agent 出问题时，你必须能回答：它那一刻的上下文里有什么、为什么选了这个工具、这一步花了多少 token、卡在第几轮。
需要埋的东西：
- 全链路 trace：每一步的输入、输出、耗时、token 数
- 单步回放：能把这个 case 拉出来，在本地复现当时的上下文
- 指标看板：任务成功率、平均轮数、单任务成本、人工介入率
这些要第一天就做。事后补埋点的成本，通常是前置做的五倍以上。
坎五：安全和成本其实是同一件事
Agent 会自动执行动作，跑偏的代价远高于 chatbot 说错话。而"跑偏"往往不是恶意，是理解偏差加上权限过大。
必要的护栏：
- 权限最小化，写操作单独授权
- 单次任务的 token 与调用次数上限，超限熔断
- 沙箱执行环境，别让它直接碰生产库
- 敏感动作二次确认
成本上，一个跑十轮的 Agent，调用量轻松是普通问答的几十倍。不设上限的 Agent，通常会在某个周末深夜给你一份惊喜账单。
三、协议层这一年，变化比模型层还大
如果说模型能力是缓慢爬坡，协议层今年是真正意义上的换挡。
MCP：工具接入的事实标准
Anthropic 在 2024 年 11 月提出 MCP（Model Context Protocol），解决的是Agent 怎么连工具和数据源。可以把它理解成 AI 世界的 USB-C：按规范写一次 Server，Claude、ChatGPT、Cursor、Copilot 都能直接调。
几个关键节点：
- 2025 年 5 月，OpenAI 在 Responses API 里支持远程 MCP Server
- 2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会旗下的 Agentic AI Foundation（AAIF），同时 OpenAI、Anthropic、Block 共同发起该基金会
- 到年底，公开的 MCP Server 已过万，主流 IDE 和云平台基本都接入了
捐给中立基金会这件事很关键------它意味着 MCP 不再是一家公司的产品，而是行业基础设施。
A2A：Agent 之间的协作层
Google 在 2025 年 4 月 9 日发布 A2A（Agent-to-Agent），基于 HTTP + SSE + JSON-RPC，解决的是Agent 之间怎么发现彼此、派活、交接状态。6 月捐给 Linux 基金会独立治理，9 月 IBM 把自己的 ACP 协议并入 A2A，社区合力做一套标准。
国内：AIP 与国标同步推进
这条线今年进展很实在：
- 2025 年 7 月，《人工智能 智能体互联 第 1 部分：总体架构》国家标准计划下达（计划号 20254281-Z-469），由中国电子技术标准化研究院牵头，北邮、华为、小米、蚂蚁、阿里、中兴等数十家单位参与起草
- 2025 年 10 月 27 日，基于该国标开发的 AIP（智能体互联协议）首版代码在开放原子开源基金会开源，由北邮人工智能学院与电子标准院共同研发
- 2026 年 6 月 26 日，市场监管总局正式批准发布 GB/Z 185.1~185.7---2026《人工智能 智能体互联》系列七项国家标准，覆盖总体架构、身份码、身份管理、智能体描述、发现、交互、工具调用
- 配套动作包括《智能体协议共建共享联合倡议》、"先锋计划"试点，以及"求索"评测基准体系；AIP 开源项目下载量已破 6000 次
这套国标有意思的地方在于，它不是另起炉灶，而是明确兼容 MCP 和 A2A，往上补了身份、发现、审计这些企业落地真正卡脖子的层。而且它给每个智能体分配唯一身份码------这在多 Agent 协作里是刚需，不然出了事根本追不到是谁干的。
分层已经收敛了
把上面几条放在一起，栈的结构其实很清晰：
| 层次 | 管什么 | 代表 |
|---|---|---|
| 能力层 | Agent ↔ 工具 / 数据 | MCP |
| 协同层 | Agent ↔ Agent | A2A |
| 治理层 | 身份、发现、审计、交易 | AIP / GB/Z 185 |
对开发者的实际含义只有一句：工具接入这块重复劳动会迅速贬值。查库、读文件、搜索、发邮件的封装，以后都是标准件。真正留下价值的地方，是业务流程设计、评测体系和领域 know-how。
所以如果你现在还在纠结"要不要自己写一层工具抽象"，答案基本是否定的------先把标准的 Server 用起来，把力气省下来投到流程上。
四、最小可用架构：六步走
从零搭一个，建议严格按这个顺序：
- 写清边界：这个 Agent 只解决什么问题，什么情况明确拒绝处理。边界模糊的 Agent 一定做不好。
- 先画图再选框架：纸上把节点、分支、失败路径画出来，标出哪些节点必须确定性执行。框架是实现细节，别反过来被框架塑造流程。
- 工具从 2--3 个开始：主链路跑通再扩。
- 记忆分层：会话内靠上下文，跨会话靠外部存储（KV 或关系库），语义检索才上向量库。别一上来就 All in 向量库。
- 建评测集：准备 20--30 个真实 case，每次改 prompt、换模型、调工具都全量跑一遍。没有评测集的 prompt 优化，本质是玄学。
- 最后才拆多 Agent：单 Agent 撑不住再拆，而且通常按"权限边界"或"专业能力"拆，不是按人的想象拆成"策划官/执行官/批评官"。
多说一句第 6 条：很多所谓多 Agent 系统，其实是一个 Agent 挂了很多工具，用 MCP 就够了。真需要 A2A 的信号是------子任务有不同的权限域、不同的运行时、或者由不同团队维护。
五、平台怎么选，以及什么时候该撤
低代码平台不是"不专业"的代名词。
流程清晰、节点有限、需要快速验证的场景------内部知识问答、表单填报、数据汇总同步------拖一两天上线，性价比远高于从零开发。这个阶段的正确目标就是跑得快。
但有三个信号出现，就该考虑往代码迁：
- 分支多到画布看不清全貌
- 需要精细控制成本、重试和兜底
- 需要自动化测试和版本管理
选型时还有一条建议值得写进评估表：**看能不能导出配置、能不能本地运行。** 平台会改版、套餐会调整，业务沉淀下来的东西应该握在自己手里。这条在 2025 年已经被验证过不止一次了。
最后
回到开头那个问题：为什么不敢上线？
因为 Demo 证明的是"它有时能做对"，生产要求的是"它出错时我知道、可控、损失有界"。这中间差的不是更强的模型，而是状态管理、工具收敛、可观测、护栏和评测这一整套东西。
好消息是，今年协议层的收敛把工具接入和跨 Agent 协作这两块变成了标准件。你要操心的事情，确实比一年前少了一层。
什么才算真正的 Agent?
区分 Agent 与"套了 LLM 壳的固定流水线"的标准只有一个：闭环能力------执行一步 → 拿到环境反馈 → 据此调整下一步。不会因反馈变化而调整行为的系统，只是自动化流水线，不具备 Agent 的适应性。
聊到这儿，说个题外话。
前面这些坑，我基本都是一个一个自己撞出来的。最近翻到北大出版社的《从零构建 AI Agent 与落地案例解析》（郭秉义、易祖洋、杜杨著），意外地发现它讲的节奏和我的体会挺接近：不绕概念，直接拿商机、财务、招聘、教育这几类真实业务，把需求拆解、工具接入到部署的流程走了一遍。12 章，十来个完整项目，而且明确是写给非技术背景的人看的，零代码也能跟着搭。
书里的界面截图会过时，但拆需求的那套思路不会。你要是正打算在公司里落第一个 Agent，可以找来当路线图翻翻。