​ 今年最常被问到的问题已经从"Agent 是什么"变成了"我做的 Agent 为什么不敢上线"。

这个问题值得认真答。因为 Demo 和生产环境之间隔着的，不是模型能力，而是一整套工程问题。这篇不列框架清单，也不聊概念之争，只讲我在实际项目里反复遇到的那些事。

![image](https://developer.qcloudimg.com/http-save/yehe-7889928/a7c0d3d3da1445635107c83009477bf2.png)![image](https://developer.qcloudimg.com/http-save/yehe-7889928/45cf913e5d9d3c9b2058033056d3dd23.gif)​

## 一、先校准一下：什么才算 Agent

有个流传很广的公式：

>**AI Agent = LLM + 规划（Planning）+ 记忆（Memory）+ 工具（Tools）**

四个部分各司其职：

|组件|作用|缺了会怎样|
|:-:|:-:|:-:|
|LLM|理解任务、推理、决定下一步|就是个普通程序|
|规划|把目标拆成步骤，处理分支和回溯|只会走直线，一遇到意外就停|
|记忆|短期上下文 + 长期偏好与历史|聊三轮就忘了最初要干嘛|
|工具|查数据库、调 API、读写文件、发消息|只能说，不能做|

但真正的分水岭不在组件齐不齐，而在于**它是不是一个闭环**：执行一步 → 拿到环境反馈 → 据此调整下一步 → 直到完成或主动终止。

判断方法很土：把上一步的执行结果改掉，看它下一步会不会跟着变。不会变，那你做的就是一条套了 LLM 壳的固定流水线。流水线也有价值，但别叫它 Agent，也别指望它有 Agent 的适应性。

## 二、Demo 到生产，五道坎

![image](https://developer.qcloudimg.com/http-save/yehe-7889928/afb016d288b8b5b53f042682e2c33dd5.png)![image](https://developer.qcloudimg.com/http-save/yehe-7889928/45cf913e5d9d3c9b2058033056d3dd23.gif)​

### 坎一：上下文是漏斗，不是水箱

新手最常见的直觉是"信息给得越多，答得越准"。实际完全相反。

上下文窗口再大，模型的有效注意力也是被稀释的。把公司制度、产品手册、几千条历史对话全塞进去，真正相关的那几条信息反而被淹没，这就是典型的"上下文腐烂"（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，通常会在某个周末深夜给你一份惊喜账单。

## 三、协议层这一年，变化比模型层还大

![image](https://developer.qcloudimg.com/http-save/yehe-7889928/36e3cf9e2f2c5cdcca95ed1789389edf.png)![image](https://developer.qcloudimg.com/http-save/yehe-7889928/45cf913e5d9d3c9b2058033056d3dd23.gif)​编辑

如果说模型能力是缓慢爬坡，协议层今年是真正意义上的换挡。

### 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 用起来，把力气省下来投到流程上。

## 四、最小可用架构：六步走

![image](https://developer.qcloudimg.com/http-save/yehe-7889928/6ab886ebc36a88e0906a87b664d43755.png)![image](https://developer.qcloudimg.com/http-save/yehe-7889928/45cf913e5d9d3c9b2058033056d3dd23.gif)​

从零搭一个，建议严格按这个顺序：


	- **写清边界**：这个 Agent 只解决什么问题，什么情况明确拒绝处理。边界模糊的 Agent 一定做不好。

	- **先画图再选框架**：纸上把节点、分支、失败路径画出来，标出哪些节点必须确定性执行。框架是实现细节，别反过来被框架塑造流程。

	- **工具从 2–3 个开始**：主链路跑通再扩。

	- **记忆分层**：会话内靠上下文，跨会话靠外部存储（KV 或关系库），语义检索才上向量库。别一上来就 All in 向量库。

	- **建评测集**：准备 20–30 个真实 case，每次改 prompt、换模型、调工具都全量跑一遍。没有评测集的 prompt 优化，本质是玄学。

	- **最后才拆多 Agent**：单 Agent 撑不住再拆，而且通常按"权限边界"或"专业能力"拆，不是按人的想象拆成"策划官/执行官/批评官"。


多说一句第 6 条：很多所谓多 Agent 系统，其实是一个 Agent 挂了很多工具，用 MCP 就够了。真需要 A2A 的信号是——子任务有不同的权限域、不同的运行时、或者由不同团队维护。

## 五、平台怎么选，以及什么时候该撤

![image](https://developer.qcloudimg.com/http-save/yehe-7889928/6f8f057b5bc39583b5c06fcf52b8db33.png)![image](https://developer.qcloudimg.com/http-save/yehe-7889928/45cf913e5d9d3c9b2058033056d3dd23.gif)​

低代码平台不是"不专业"的代名词。

流程清晰、节点有限、需要快速验证的场景——内部知识问答、表单填报、数据汇总同步——拖一两天上线，性价比远高于从零开发。这个阶段的正确目标就是跑得快。

但有三个信号出现，就该考虑往代码迁：


	- 分支多到画布看不清全貌

	- 需要精细控制成本、重试和兜底

	- 需要自动化测试和版本管理


选型时还有一条建议值得写进评估表：**看能不能导出配置、能不能本地运行。**​ 平台会改版、套餐会调整，业务沉淀下来的东西应该握在自己手里。这条在 2025 年已经被验证过不止一次了。

## 最后

回到开头那个问题：为什么不敢上线？

因为 Demo 证明的是"它有时能做对"，生产要求的是"它出错时我知道、可控、损失有界"。这中间差的不是更强的模型，而是状态管理、工具收敛、可观测、护栏和评测这一整套东西。

好消息是，今年协议层的收敛把工具接入和跨 Agent 协作这两块变成了标准件。**你要操心的事情，确实比一年前少了一层。**


### 什么才算真正的 Agent?

区分 Agent 与"套了 LLM 壳的固定流水线"的标准只有一个：**闭环能力**——执行一步 → 拿到环境反馈 → 据此调整下一步。不会因反馈变化而调整行为的系统，只是自动化流水线，不具备 Agent 的适应性。


----

聊到这儿，说个题外话。

前面这些坑，我基本都是一个一个自己撞出来的。最近翻到北大出版社的《从零构建 AI Agent 与落地案例解析》（郭秉义、易祖洋、杜杨著），意外地发现它讲的节奏和我的体会挺接近：不绕概念，直接拿商机、财务、招聘、教育这几类真实业务，把需求拆解、工具接入到部署的流程走了一遍。12 章，十来个完整项目，而且明确是写给非技术背景的人看的，零代码也能跟着搭。

![image](https://developer.qcloudimg.com/http-save/yehe-7889928/150d954a469b18efe4cdebc186782999.jpg)![image](https://developer.qcloudimg.com/http-save/yehe-7889928/45cf913e5d9d3c9b2058033056d3dd23.gif)​

书里的界面截图会过时，但拆需求的那套思路不会。你要是正打算在公司里落第一个 Agent，可以找来当路线图翻翻。

​

​ 今年最常被问到的问题已经从"Agent 是什么"变成了"我做的 Agent 为什么不敢上线"。

AI Agent 落地这一年：从“能跑起来”到“敢放出去”

为什么大多数 Agent 项目止步于 Demo，不敢上线？答案不在模型能力，而在一整套工程体系——上下文管理、工具收敛、状态机设计、可观测性和安全护栏。文章结合作者实战经验，系统拆解了这五道坎，并梳理了 MCP / A2A / AIP 等协议层今年的关键进展，最后给出了一套"最小可用架构"的六步落地路径。

技术主管

人工智能

架构设计

开发工具

今年最常被问到的问题已经从"Agent是什么"变成了"我做的Agent为什么不敢上线"。区别不在模型能力，而是一整套工程问题：上下文管理、工具收敛、状态控制、可观测性和安全护栏。构建真正的Agent需闭环能力——执行、反馈、调整。协议层已趋成熟（MCP、A2A、国标），建议从明确边界、小工具集起步，建立评测集，选能导出的平台。

智能体

LangGraph

数据库

ChatGPT

Linux

Agent

JSON

腾讯云双十一大促

llmsgw

weda

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

今年最常被问到的问题已经从"Agent是什么"变成了"我做的Agent为什么不敢上线"。区别不在模型能力，而是一整套工程问题：上下文管理、工具收敛、状态控制、可观测性和安全护栏。构建真正的Agent需闭环能力——执行、反馈、调整。协议层已趋成熟（MCP、A2A、国标），建议从明确边界、小工具集起步，建立评测集，选能导出...

AI Agent 落地这一年：从“能跑起来”到“敢放出去”-腾讯云开发者社区-腾讯云

AI Agent 落地这一年：从“能跑起来”到“敢放出去”

AI Agent 落地这一年：从“能跑起来”到“敢放出去”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐