什么是 AI 智能体：从大语言模型到自主执行系统

如果大语言模型已经能写代码、分析文档、制定计划，为什么还要创造“Agent”这个概念？把模型接上几个 API，不就已经可以工作了吗？

这个问题背后真正的矛盾是：语言模型擅长生成下一段内容，但真实任务要求系统持续改变外部状态，并对改变后的结果负责。 一段看起来正确的回答，与一个在不确定环境中完成任务的系统，中间隔着状态、反馈、权限、失败恢复和验收。

What：Agent 到底是什么

Agent 并没有唯一公认的定义。不同产品会把固定工作流、能调用工具的聊天机器人，甚至一个带人格的 Prompt 都称为 Agent。为了讨论工程问题，可以使用一个更严格的定义：

Agent 是一个围绕目标运行的闭环系统。它持续观察环境，根据当前状态决定下一步行动，通过工具影响环境，再利用行动结果更新判断，直到目标完成、预算耗尽或需要人类介入。

可以把它表示为：

目标 G
  ↓
观察 Oₜ → 策略/模型 π → 行动 Aₜ → 环境状态 Sₜ₊₁
  ↑                                  ↓
  └──────────── 新的观察 Oₜ₊₁ ────────┘

这里的大语言模型只是策略的一部分。真正让系统成为 Agent 的，不是模型“会思考”，而是它被放进了一个能够反复行动和接收反馈的控制回路。

这也解释了 Agent 与 Workflow 的差别。Workflow 的路径主要由开发者在代码中预先规定；Agent 的下一步路径主要由模型根据环境动态选择。两者并非互斥：生产系统往往用确定性 Workflow 约束外层边界，在局部开放 Agent 决策。

一次模型调用隐含了几个不适合现实任务的假设。

第一，它假设完成任务所需的信息已经全部出现在输入中。但排查线上故障时，真正关键的信息可能藏在日志、监控、配置和最近提交里，必须边探索边缩小范围。

第二，它假设模型生成的计划可以直接成立。现实环境会拒绝请求、返回异常、暴露新的依赖。计划必须随着观察改变，而不是在任务开始时一次写死。

第三，它假设输出文本就是最终结果。用户要的是“服务恢复”“报告已生成”或“测试通过”，而不是一段描述如何完成这些工作的文字。

第四，它没有天然的时间连续性。模型调用结束后，计算状态消失。长任务需要外部 Runtime 保存计划、事件、工具结果与恢复点。

Agent 正是为这些问题而存在：它把静态的生成能力转化为动态的任务执行能力。

Agent 首先解决的是路径无法提前完全枚举的问题。开放式调研、复杂代码修改、跨系统运维都具有路径依赖：下一步做什么，要看上一步发现了什么。固定流水线可以覆盖已知分支，却难以覆盖组合爆炸的未知分支。

其次，它解决了模型与外部世界之间的反馈问题。ReAct 提出的“推理与行动交错”，核心价值并不是让思维链更长，而是让模型能够用搜索、知识库或环境反馈修正内部判断。行动为推理提供事实，推理为行动提供方向。

但 Agent 并没有自动解决正确性。模型可能选错工具、误解返回值、在失败后形成错误解释，甚至为了完成目标绕过约束。工具调用能力放大了模型的效用，也放大了错误的影响半径。

因此，Agent 不是“更聪明的模型”，而是“更有能力、同时也更需要治理的系统”。

模型之外至少还有六层。

目标与验收定义何为完成。目标必须与验收分离：模型可以声称完成，但测试、状态查询或人工确认才是证据。

上下文系统决定每轮模型真正看到什么，包括规则、用户目标、历史、检索材料和工具反馈。上下文不完整，模型就会在错误的世界模型上做出合理但无效的决策。

工具系统把文件、数据库、浏览器和业务 API 暴露为结构化能力。Schema 只是入口，权限、超时、幂等和错误语义才决定工具是否可靠。

Runtime维护循环、状态、取消、重试、预算和恢复。它相当于 Agent 的执行骨架。

安全边界限制可访问的资源和副作用。沙箱、最小权限、敏感操作确认以及来源隔离不能只依赖 Prompt。

可观测与评估记录模型请求、工具调用、状态变化、成本和最终结果。没有轨迹，就无法区分模型问题、上下文问题和工具问题。

Agent 用灵活性换来了不确定性。一个固定 API 调用可能几十毫秒完成，而 Agent 需要多轮模型推理和工具交互，延迟与成本都更高。相同输入也不一定产生完全相同的执行路径，测试和复现更困难。

它还引入了新的安全问题。传统软件的调用路径由代码决定，Agent 的路径则部分由模型生成；不可信网页、文档和工具返回值可能影响后续决策。权限设计必须假设模型会犯错，而不是假设模型会服从所有文字规则。

对于规则清楚、路径固定、失败代价高的任务，普通程序或 Workflow 通常更合适。只有当任务的路径确实依赖动态信息，且成功价值足以覆盖成本时，Agent 才带来净收益。

Agent 的研究难点正在从“能不能调用工具”转向“能不能长期可靠地行动”。我们仍缺少对长程任务足够可信的评估：一次成功无法说明系统在环境变化、工具失败和恶意输入下仍然可靠。

另一个问题是信用分配。当一次二十步任务失败，到底是早期规划错误、记忆污染、工具描述误导，还是最后验收不足？没有更细粒度的因果分析，优化只能依赖经验。

最后是自主性边界。能力更强是否意味着应该给予更大权限？并不必然。一个可靠的 Agent 需要的不只是更强推理，还要能表达不确定性、主动缩小行动范围，并在证据不足时停下来。

可以用一个简单问题检验某个产品是否真的需要 Agent：如果把模型的下一步选择替换成固定代码，任务是否仍能完成？如果答案是可以，那么它更可能只是一个带模型节点的 Workflow。只有当环境信息不断改变，开发者无法经济地枚举路径，而模型的动态决策能够被外部证据验证时，Agent 抽象才真正成立。

Agent 最值得关注的地方，不是它让模型看起来更像人，而是它改变了软件的控制方式：开发者不再枚举所有路径，而是定义目标、能力、约束与验收，让模型在边界内寻找路径。

这是一种强大的抽象，也是一种危险的抽象。未来真正有价值的 Agent 系统，不会把自主性最大化，而会让自主性可配置、可观察、可暂停、可验证。