- 用户目标
描述问题、贴代码、请求解释
- 模型回答
生成片段、解释报错、给方案
- 输出结束
这一轮通常停在“答案已经给出”
Agent 是怎么工作的
约 1041 字大约 3 分钟
2026-05-25
Agent 不是更会聊天的模型，而是模型、上下文、工具、运行环境、约束和验证共同组成的执行系统。
AGENT LOOP
Chat 在回答你，Agent 在替你推进任务。
真正的变化不是模型更能说，而是它开始读上下文、执行动作、观察结果，再决定下一步。执行闭环一旦出现，风险和收益都会一起放大。- 用户目标
任务、约束、验收标准
- 装载上下文
项目文件、规则、历史结果
- 模型计划
决定下一步动作
- 执行 Tool
读文件、跑命令、改代码
- 观察结果
stdout、diff、截图、报错
- 验证 / 输出
继续迭代或提交结果
FAILURE POINTS
第一次接触 Agent，最容易在闭环里失控。
- 目标太大，一轮里混了创建项目、做整页、适配移动端和构建检查。
- 上下文不全，没有告诉 Agent 技术栈、目录结构和禁止操作。
- 工具权限给得太快，没看命令、没看 diff，就让它继续写。
- 看到了输出，但没跑验证，所以“看起来做完”其实没有闭环。
发展原因
Chat 适合解释、讨论和生成片段。但真实工程任务通常需要读取项目、修改多个文件、运行命令、观察错误、继续修复。到了这一步，任务已经不只是“回答一个问题”，而是在推进一个真正会影响项目状态的执行过程。
更直接地说：Chat 模型是在回答你，Agent 是在替你推进任务。
当任务需要进入代码库、调用工具、读取真实输出来做下一步判断时，单轮问答就不够了，Agent 才有存在意义。
Agent 的最小组成
| 组成 | 作用 | 常见失败点 |
|---|---|---|
| 模型 | 推理、生成计划、选择动作 | 误解目标、过度自信 |
| 上下文 | 当前任务、项目文件、历史对话 | 上下文缺失或污染 |
| Memory | 长期偏好、项目约定、历史决策 | 把旧记忆当事实 |
| Tool | 读文件、改代码、跑命令、查资料 | 权限过大或结果误读 |
| 环境 | Git、依赖、终端、浏览器、测试 | 环境不可复现 |
| 约束 | 项目规则、安全边界、完成标准 | 没有明确边界 |
| 验证 | 构建、测试、预览、人工审查 | 只看输出不看结果 |
工作循环
最小工作循环可以按六步理解：
目标进入当前任务不是一句模糊请求，而是带约束和验收标准的任务。装载上下文项目文件、规则、历史结果、当前工作区状态一起进入判断。模型决定下一步它要先判断该回答、该读文件、还是该执行命令。工具执行动作真正的副作用发生在这里，比如读文件、改代码、跑构建。观察结果stdout、diff、报错、截图会回写到下一轮。验证或输出要么继续修正，要么明确给出结果和验收说明。
所以 Agent 的关键不只是“有工具”，而是工具结果会继续影响下一轮。没有这一步，就还是聊天；有了这一步，才叫执行闭环。
Agent 容易失败的位置
目标模糊、权限过大、没有验证、上下文污染、错误级联，是最常见的五类问题。解决方式不是“换更强模型”这么简单，而是把任务边界和检查点设计好。
失败点
第一次接触 Agent，最常见的失败并不是“模型太弱”，而是闭环管理出了问题：
目标太大一次让它创建项目、写整页、适配移动端、跑构建，最后你很难判断哪一步出了问题。上下文不足没说技术栈、目录约定、禁止操作和验收标准，Agent 只能自己猜。工具权限失控命令和修改范围没看清，就一路放行，结果很容易改过头。结果没有回写看到了报错或页面问题，却没有把具体观察结果反馈给下一轮。没有验证它说“已经完成”，但你没看 diff、没跑构建、没开页面。
这些问题的解决方式都不是抽象的“提示词更专业”，而是更具体的任务拆分、权限控制和结果检查。
后续结构
这一篇只解决 Agent 的最小心智模型。后面的文章分别补它闭环里的不同缺口：
Memory：解决“带着上下文持续工作”Skill：解决“把稳定流程沉淀成可复用能力”MCP：解决“连接外部系统和能力入口”Tool：解决“真正执行动作的接口和风险”Hook：解决“关键节点的自动检查和约束”
如果你先理解这一篇的闭环，再去看后面的分篇，就不会把这些概念当成零散术语，而会知道它们分别在补哪一块能力。
