向模型提一个问题，它给一段回答——这个交互模式大家都熟了。AI Agent 带来的变化是：它不只回答，还能搜资料、调工具、跑代码、自主完成一串任务。从"回答问题"到"完成任务"，中间隔着一套完全不同的工程结构。这篇文章把这套结构拆开讲透，再讲清楚它为什么经常失败。
三个概念先分清
- LLM：负责理解和生成。它能写出一段代码，不代表能在你机器上执行——执行永远需要外部程序；
- Chatbot：以对话为中心的交互形态。现代聊天机器人也可以接工具，所以不能简单说它没有行动能力；
- AI Agent：以目标和任务执行为中心，能根据任务状态动态决定下一步。
三者不是互斥分类——一个 Chatbot 内部完全可以采用 Agent 架构。真正的分界线不是界面上有没有聊天框，而是系统是否具备自主决策和持续执行的能力。
四个组成部分与执行循环
典型 Agent 拆开是四件套：LLM（决策大脑）、Tools（工具箱：搜索、浏览器、文件、代码执行、数据库、外部API）、Memory（短期存会话状态，长期存用户偏好和项目知识）、Planning（预先规划或动态决策，ReAct、Plan-and-Execute 是常见思路）。
让这些部件协同起来的机制是 Agent Loop：感知 → 决策 → 行动 → 观察 → 再决策。看一个修 Bug 的五轮循环就明白了：第一轮读代码定位问题，第二轮改代码，第三轮跑测试发现失败，第四轮读报错重新修改，第五轮测试通过收工汇报。这不是五次独立对话，是同一个任务里持续进行的决策与执行。
模型提出工具调用请求，运行系统负责真正执行——这个分工是理解 Function Calling 的基础。延伸到协议层，三个概念各管一层：Function Calling 解决"模型如何提出结构化调用"，MCP 解决"应用如何标准化连接工具"，A2A 解决"Agent 之间怎么通信"。它们是组合关系，不是替代关系。
增量点：可靠性为什么天然是乘法问题
Agent 最大的生产隐患藏在一道算术里：一个任务要连续执行 20 步，每步成功率 95%，端到端一次成功的概率只有 0.95²⁰ ≈ 35.8%。单步表现不错，不等于端到端可靠。
这道算术直接推出生产系统的四个必备件：
- 验证机制——每步执行后有客观的成败判定，不靠模型自评；
- 错误重试——配合幂等键，防止重试产生重复副作用（比如重复下单）；
- 状态恢复——失败后从检查点续跑，不从头再来；
- 人工介入——低置信度或高风险动作挂起等审批。
增量点（D类）：把 95% 拆成可测的单步指标。 实践中先统计每类动作的成功率（工具调用成功率、解析成功率、验证通过率），找出最弱的环节先修。端到端成功率是各步的乘积，补短板永远比整体调优收益大——把 60% 的那一步提到 90%，比把 95% 的三步都提到 98% 有效得多。
增量点：什么任务不该用 Agent
不是所有任务都需要智能体。三个判断问题：
- 任务是否需要根据动态信息决定下一步？——步骤完全固定的任务（定时读库出报表），传统工作流更可靠；
- 是否需要组合多种工具做多步操作？——工具多本身不是用 Agent 的理由，得看步骤之间有没有依赖判断；
- 权限和失败处理能不能清晰定义？——定义不了权限边界的高风险场景，先别上。
一句话准则：固定、可预测的任务用传统自动化；需要动态决策的复杂任务才考虑 Agent；两者可以混搭。
成本、安全与幻觉
除可靠性外还有三笔账。成本：复杂任务多轮推理加工具调用，token 消耗是普通问答的几十倍，预算要按轮数上限估算。安全：Agent 能碰文件和业务系统后，一次错误决策就是真实影响——权限最小化、工具隔离、操作审计、关键操作审批缺一不可，还要防恶意网页诱导的提示注入。幻觉：普通聊天里错一句无妨，Agent 场景里错误会进入后续决策链，RAG 和事实验证能缓解但不能根除。
收束
Agent 的实际表现不由模型单独决定。同一个 LLM，在不同的上下文组织、工具设计、状态管理和失败恢复机制下，效果可以差出一个量级。可以把 Agent 理解成两部分：模型提供的智能，加上运行系统提供的执行与管理。多 Agent 拆分只在单 Agent 明显失控时才考虑——通信、状态同步和成本管理会随数量上升，架构的目标是提高任务完成效果，不是堆 Agent 数量。理解这些工程机制，和理解模型能力同样重要。
评论0