“Agent”经常被描述成会自己完成任务的 AI，但这句话还不够准确。一个聊天模型可以生成很好的答案，却不一定能查数据、修改文件、调用服务，更不一定知道什么时候应该停下来验证结果。
更实用的定义是：**Agent 是以大语言模型为决策核心，利用上下文理解状态，通过工具改变外部世界，并在反馈中继续行动的系统。**模型是大脑，但完整的 Agent 还需要记忆、工具、约束和反馈回路。
一、模型和 Agent 到底差在哪里
一次普通的 LLM 调用大致是：输入消息，得到输出。输出可以是文字、结构化数据或一段代码，但调用结束后，模型本身并没有完成外部动作。
Agent 则把一次调用放进了一个循环：
任务 -> 读取状态 -> 模型决定下一步 -> 调用工具 -> 获得观察结果 -> 再决定这个循环让模型拥有了行动能力，也带来了新的问题：工具调用可能失败，外部数据可能过期，模型可能误解目标，多个步骤之间可能积累错误。因此 Agent 的难点不是“让模型多说几句话”，而是让每一步都能被观察和纠正。
可以把 Agent 的输入输出分成两个空间：
| 空间 | 例子 |
|---|---|
| 观察空间 | 用户需求、文件内容、搜索结果、接口响应、测试日志 |
| 行动空间 | 回复用户、搜索、读写文件、执行命令、提交任务 |
Agent 的质量，取决于它是否看到了完成任务所需的事实，以及行动空间是否足够明确、足够安全。
二、ReAct：把思考和行动接起来
ReAct 的核心不是让模型展示一段很长的思维过程，而是让“分析下一步”和“执行动作”交替发生。一个简化的运行时可以写成：
state = load_initial_context(task)
while not state.finished:
decision = model.decide(state)
if decision.kind == "tool_call":
result = tools[decision.name].run(decision.arguments)
state = state.observe(result)
elif decision.kind == "final_answer":
state = state.finish(decision.content)
else:
state = state.observe("invalid action")这里有三个容易被忽略的设计点。
第一，工具结果必须回到上下文中，否则下一轮模型不知道刚才发生了什么。第二，工具参数需要在执行前校验，不能把模型生成的 JSON 直接当成可信命令。第三，循环必须有结束条件，例如完成信号、最大步数、预算或人工确认。
三、为什么“能调用工具”还不等于可靠
如果只给模型一组函数，Agent 可能出现三类失败：
- 方向错误：目标没有被拆解，模型在无关信息上反复搜索。
- 执行错误：参数格式正确，但对象、权限或业务语义不正确。
- 验证缺失：工具返回成功，结果却没有真正满足用户目标。
因此生产系统通常还需要一层 Harness。它负责提供上下文，暴露工具，限制权限，记录轨迹，运行验证，并在失败时把具体反馈交给下一轮。比如“请不要破坏现有功能”应该落实为回归测试；“请修改代码”应该落实为受限工作区、类型检查和测试结果。
可以用这个公式理解两者的关系：
Agent = LLM + 上下文 + 工具 + 约束 + 验证 + 纠正模型擅长从不完整信息中提出候选方案，Harness 则把候选方案放到真实环境中检查。两者之间不是替代关系，而是闭环关系。
四、什么时候该用 Agent
适合使用 Agent 的任务通常具有三个特征：步骤数量不固定，需要根据中间结果选择下一步，并且存在可调用的外部工具。例如排查线上故障、整理一批文档、完成跨系统的信息核对。
如果任务流程完全固定，普通工作流往往更容易测试和维护。只有当“下一步依赖观察结果”时，才需要把决策交给模型。Agent 不是流程编排的升级版，而是把流程中的不确定决策交给模型处理。
开始设计时，可以先回答四个问题：
- 它需要观察哪些事实？
- 它可以执行哪些动作？
- 哪些动作必须先获得确认？
- 什么证据能够证明任务完成？
这四个答案比一段很长的系统提示词更能决定 Agent 是否可靠。
参考阅读
- 李博杰：《深入理解 AI Agent：设计原理与工程实践》，v1.3，2026-07-29。