AI Agent 深度解析：从核心公式到工程实践
本文核心思想源自《AI Agents 深入浅出》（AI-Agents-in-Depth）一书，结合工程实践进行系统梳理。
一、Agent 的核心公式
1.1 Agent = LLM + 上下文 + 工具
这是贯穿全书的最核心公式。一个最小可工作的 Agent 只需要三样东西：
- LLM（大脑） — 负责理解、推理和决策的智能核心
- 上下文（眼睛） — Agent 在每个决策点能看到的全部信息
- 工具（手脚） — Agent 与外部世界交互的桥梁
这三者缺一不可。没有工具，Agent 只能”纸上谈兵”；没有上下文，Agent 如同盲人摸象；没有 LLM，Agent 就失去了智能的核心。
Agent 产品的三个维度展开：
| Agent 产品 | 眼睛（感知） | 手脚（行动） | 策略 |
|---|---|---|---|
| Coding Agent | 代码库、终端环境 | 文件读写、命令执行 | 理解需求 → 搜索代码 → 编辑 → 测试 |
| 搜索 Agent | 网络资源、数据库 | 搜索查询、摘要生成 | 迭代深化，逐步综合报告 |
| 电脑操控 Agent | 屏幕画面 | 点击、输入、滚动 | 视觉感知 → 操作 → 验证 |
| 个人办事 Agent | 账户信息、账单 | 打电话、发邮件、填表单 | 收集信息 → 协商策略 → 执行 |
1.2 三层理解
公式可以从三个层次来理解：
实现层： 从 API 角度看，Agent 就是在一个循环中调用 LLM，每次调用时传入上下文，LLM 返回文本或工具调用请求，执行工具后将结果追加到上下文，继续下一轮。
直觉层： Agent = 大脑（LLM）+ 眼睛（上下文）+ 手脚（工具）。大脑负责思考，眼睛负责感知，手脚负责行动。
学术层： 借鉴计算机体系结构中的”指令集架构”概念，LLM 是 Agent 的”大脑”（计算核心），上下文是”观察空间”（Agent 能看到什么），工具是”动作空间”（Agent 能做什么）。许多看似需要”更聪明模型”的问题，其实只是接口问题——把任务所需的数据纳入上下文，或把完成任务所需的操作封装成工具。
1.3 从工作流到自主 Agent 的编排光谱
Agent 系统的编排方式是一个连续谱，一端是确定性的工作流，另一端是完全自主的 Agent：
- 工作流（Workflow） — 执行路径由代码预先定义，LLM 只在每个节点内部负责理解和生成。适合流程固定、有严格合规要求的场景。
- 自主 Agent（Autonomous Agent） — 执行路径由 Agent 根据环境反馈实时决定，本质是在一个循环中使用工具的 LLM。适合开放式、难以预测步骤数量的任务。
实践中两者并非非此即彼，很多系统会混合使用：关键流程用工作流确保可靠性，灵活决策部分切换到自主模式。
二、Harness 工程：模型之外的竞争力
2.1 什么是 Harness
Harness 原指马具，是套在马身上的缰绳与挽具。在 Agent 语境中，模型是那匹强大但不可预测的马，Harness 则是把它的能力引导成可靠任务执行的工程外壳。
核心观点： 模型之外的全部基础设施都属于 Harness。当各家模型的能力越来越接近时，竞争优势就转移到了模型之外的工程实践。
2.2 Harness 的五功能模型
| 功能 | 一句话职责 | 核心原则 |
|---|---|---|
| 上下文（Context） | 为模型提供感知信息 | 信息充分性：每个决策点都基于足够信息判断 |
| 工具（Tools） | 为模型提供行动手段 | 接口清晰：命名直观、参数有例子、边界有说明 |
| 约束（Constrain） | 设定行为边界 | 默认安全：所有能力默认关闭，必须显式开放 |
| 验证（Verify） | 自动判断操作结果的对错 | 输入隔离：安全检查只看结构化数据，而非模型自由生成的文本 |
| 纠正（Correct） | 发现问题时自动修正或回退 | 不暴露中间态：失败时先静默重试，不将半成品展示给用户 |
五个功能构成一个闭环：上下文与工具支撑决策，约束预防错误，验证发现偏差，纠正闭合循环。缺少任何一个环节，系统都会出现可靠性缺口。
2.3 工程范式的演进
AI 应用工程的发展经历了清晰的演进弧线：
- 软件工程 — 基础：传统的系统设计、架构、测试和部署
- 提示工程（Prompt Engineering） — 第一波：优化输入给模型的自然语言指令
- 上下文工程（Context Engineering） — 第二波：系统性地管理模型能看到的所有信息
- Harness 工程 — 第三波：从”模型能看到什么”扩展到”模型在什么样的系统中运行”
- Loop 工程 — 第四波：从单次运行扩展到跨轮次的持续自主运转
- Graph 工程 — 第五波：把 Agent 循环、确定性程序和人工审批组织成显式的执行图
这五个阶段不是替代关系，而是层层包含的。每一层都在前一层的基础上扩展了工程师的关注范围和影响力。
2.4 构建有效 Agent 的核心原则
根据 Anthropic 与数十个团队合作的经验，成功的 Agent 系统遵循三个核心原则：
保持简单： 从最简单的方案开始，只在确实必要时才增加复杂度。直接的 API 调用优于复杂的框架，清晰的代码优于聪明的抽象。
保持透明： 明确显示 Agent 的规划步骤、执行日志和决策轨迹——这不只是为了调试方便，也是让用户建立信任的前提。
设计好工具接口（ACI）： ACI 强调的是从 Agent 视角设计接口，让 Agent 容易理解和使用。工具的命名和参数要直观，容易误用的地方要从设计上让错误无法发生——就像 SIM 卡的缺角让卡片只能从一个方向插入。
2.5 模型选型策略
模型是 Agent 的智能基座，选对模型往往比优化提示词更有效：
- 闭源模型：Claude（复杂推理、编程突出）、Gemini（超长上下文、多模态）、GPT/o 系列（均衡）
- 国内模型：豆包（低延迟）、Kimi（Agent 能力较强）、Qwen/DeepSeek（开源可定制）
- 开源 vs 闭源：闭源能力领先但成本高，开源可私有化部署和微调
- 思考能力：绝大多数 Agent 需要支持思考的模型，只有单步简单任务场景例外
- 输出速度：Agent 往往需要多轮推理，输出速度直接决定端到端延迟
三、上下文工程
3.1 上下文的五个组成部分
每次调用 LLM 时的上下文由以下部分构成：
- 系统提示词（System Prompt） — Agent 的”岗位说明书”，定义身份、权限和行为准则
- 工具定义（Tool Definitions） — 声明 Agent 可用工具的名称、功能描述和参数格式
- 对话历史 — 当前会话中之前的问答记录
- 检索结果 — 从外部知识库中检索到的相关信息
- Agent 状态 — 当前执行进度、中间结果等运行时状态
3.2 上下文管理的关键挑战
- 上下文窗口限制：信息太多时需要进行压缩和精简
- 信息噪声：无关上下文会制造噪声，干扰模型判断
- 时效性：过时的信息会导致错误决策
- 按需加载：真正有效的扩展应当是按需、相关且可控的
3.3 记忆与知识库
Agent 的记忆可以分为三个层次：
- 任务内适应：在当前上下文中通过示例、状态和检索结果即时调整行为，任务结束后不自动保留
- 跨任务外部产物更新：将经验沉淀为知识文档、指令或程序，可审计、可修订
- 模型参数更新：通过后训练将高维能力写入模型参数，部署成本高但泛化能力强
四、工具设计
4.1 工具的五分类
根据 Agent 与外界互动的方向，工具可以分为五类：
| 类型 | 作用 | 示例 |
|---|---|---|
| 感知工具 | 让 Agent 能访问信息 | 搜索引擎、文件系统、API、数据库 |
| 执行工具 | 让 Agent 改变世界 | 代码执行、文件操作、系统命令 |
| 协作工具 | 让 Agent 与其他 Agent 分工合作 | 委托子 Agent、请求人类确认 |
| 事件触发工具 | 外部输入驱动 Agent 开始执行 | 收到邮件、定时触发、Webhook |
| 用户沟通工具 | Agent 主动与用户传递信息 | 文字消息、语音通话、邮件 |
4.2 工具设计原则
- 从最窄能力起步：先以完成任务所需的最窄能力开始，随复杂度提升逐步扩展
- 通用 vs 专用：通用工具用于组合与探索，专用工具用于约束高风险操作
- 防呆设计（Poka-yoke）：从设计上让错误无法发生，而非依赖用户正确使用
- 安全沙盒：代码必须在隔离沙盒中运行，默认不能访问网络，限定执行时间、内存和输出大小
4.3 MCP 协议
MCP（Model Context Protocol）标准的推广，正在让工具接入变得更像安装插件。它提供了标准化的工具定义和调用协议，使 Agent 可以动态发现和使用各种外部工具。
五、Agent 的评估
5.1 评估的核心挑战
Agent 评估比传统软件测试更复杂，因为：
- 开放性：Agent 的执行路径不固定，同一个任务可能有多种正确的完成方式
- 多轮交互：需要在多轮交互中评估整体表现，而非单次输出
- 环境依赖：评估结果依赖环境状态，需要可控的评估环境
5.2 评估体系
- 自动评估环境：工具调用型评估环境、人机交互型评估环境
- 评估任务数据集：需要精确的任务描述、层次化的复杂度、可验证的客观标准
- 评估指标：任务完成率、工具调用正确率、效率、安全性等
- LLM-as-a-Judge：用 LLM 评估 Agent 的输出质量，是自动化评估的核心方法
5.3 从评估到持续改进
评估不是终点，而是持续改进的起点。评估结果应该反馈到 Harness 的优化中，形成”评估 → 发现问题 → 改进 Harness → 重新评估”的闭环。
六、代码生成：Agent 的元能力
6.1 代码作为 Agent 的元能力
代码生成是 Agent 最独特的能力之一——它让 Agent 能够创造新工具、修改自身行为，甚至改进自己。
代码在 Agent 中的五种角色：
- 思考工具 — 通过编写代码来辅助推理和计算
- 业务规则约束 — 将不确定的 LLM 输出转化为确定性的代码执行
- 多媒体生成 — 通过代码生成图表、文档、报告等
- 系统适配器 — 通过代码连接不同的系统和 API
- 生成式 UI — 通过代码动态生成用户界面
6.2 Coding Agent 的实现技巧
成功的 Coding Agent 需要：
- 准确的代码搜索：能快速定位相关代码
- 安全的文件编辑：精确的编辑操作，避免破坏现有代码
- 可靠的错误恢复：编译错误时能自动分析和修复
- 增量开发：理解需求 → 搜索相关代码 → 编辑代码 → 测试验证 → 调试修复
七、多 Agent 协作
7.1 两个核心设计维度
多 Agent 系统有两个正交的核心设计维度：
维度一：上下文是否共享
- 共享上下文：后续 Agent 继承前序 Agent 的完整上下文，信息零损耗但上下文膨胀快
- 不共享上下文：完全独立的多 Agent 协作，通过提炼后的移交包、文件系统或消息传递来交换信息
维度二：协作拓扑
- 对等模式：多个 Agent 相互制衡、迭代改进，适合少量 Agent 的场景
- 管理者模式：一个 Manager Agent 负责任务分解和结果整合，适合需要动态调度的复杂任务
- 去中心化模式：职责对等，控制权在 Agent 之间自主流转，适合需要灵活协调的场景
7.2 多 Agent 何时优于单 Agent
核心准则：协作过程是否引入了生成时不存在的新信息。
如果多个 Agent 只是重新审视同一段文本（如辩论模式），在等量计算资源下单 Agent 同样有效。但如果 Reviewer 能获得外部反馈——代码执行结果、视觉渲染截图、工具验证输出——多 Agent 的优势就是实质性的。
7.3 基础设施：与操作系统类比
多 Agent 系统的基础设施设计蓝本来自操作系统：
| 操作系统概念 | Agent 世界对应 |
|---|---|
| 进程 | Agent 运行时实例 |
| 程序 | 静态前缀（系统提示词 + 工具定义） |
| 内存 | 轨迹（Trajectory） |
| CPU 分时复用 | LLM 调用调度 |
| 文件系统 | 共享工作区（虚拟目录树） |
| 进程间通信 | Agent 间消息传递 |
| 死锁检测 | 级联终止机制 |
7.4 Agent 社会
当 Agent 数量足够多时，会产生无法预先设计的集体行为：
- 斯坦福 AI 小镇：25 个 Agent 自发传播消息、协调组织聚会
- Agentopia：将模拟拉长到 10 年，用”生活奖励”从模拟经验中筛选轨迹
- Moltbook：150 万 Agent 涌现出数字宗教和机器原生协作协议
- Vending-Bench Arena：相互竞争的 Agent 打起了价格战、甚至自发合谋定价
- Pinchwork / RentAHuman：Agent 通过市场机制互相雇佣，甚至用加密货币雇佣人类
八、持续进化
8.1 从经验到更新的四种路径
Agent 如何从运行经验中学习并改进自己：
- 将经验沉淀为知识 — 写入知识文档，供后续检索
- 将经验写成指令 — 更新 Prompt 或 Skill，引导模型行为
- 将经验写成程序 — 更新 Harness 或工具，将经验固化到代码中
- 将经验写入参数 — 通过后训练更新模型权重
8.2 持续进化闭环
真正的持续进化需要构建完整的闭环：
- 问题定位 — 通过评估和监控发现 Agent 的不足
- 经验沉淀 — 将问题原因和解决方案整理成可复用的形式
- 验证发布 — 在安全环境中验证更新效果
- 回滚机制 — 在更新失败时快速回滚到稳定状态
九、模型与 Agent 的共同演进
9.1 两朵乌云
当前 Agent 领域面临两大核心挑战：
第一朵乌云：实时交互。 今天绝大多数 Agent 仍是按轮次的”请求-应答”模式，但真实世界不会停下来等它想完。走向实时性有两条路：一是架构上做快慢分离（前台快模型维持对话节奏，后台慢模型负责深度思考），二是把推理本身做快。
第二朵乌云：持续学习。 今天的模型更像一个记性极好、却学不会新东西的天才。训练时把人类知识背得滚瓜烂熟，上岗后却几乎不再成长。模型最强的能力，终将不是记住，而是学习与适应。
9.2 模型与 Harness 的共同演进
回头看那些 Harness 里层层叠叠的兜底逻辑——每一段看似”丑陋”的代码，记录的都是模型此刻还做不稳的地方。当下一代模型把这些约束内化，对应的代码就可以删掉。
这是一条自我强化的飞轮：
用户提出真实的难题 → 应用层用 Harness 把模型暂时做不好的事补上 → 这些补救再反过来变成模型下一次迭代的训练信号
模型每稳定内化一种能力，对应的 Harness 层就可以删掉。但这个”吃”永远不会完结：一是训练以月计，模型等得起，业务等不起；二是模型无法内化真实业务中所有的约束与偏好；三是每一代模型都会打开新的能力前沿，而前沿处恰恰是模型最做不稳的地方。
这意味着： 如果你在造模型，护城河就是把这条飞轮转起来——让真实场景的反馈尽快回流到训练里。如果你在模型之上造应用，Harness 是你短期最锋利的技术杠杆，但要清醒：模型每内化一层约束，就会顺手抹平一批只靠 Harness 建立的优势。应用层真正长久的护城河，往往在技术之外——独占的数据、稳固的渠道、用户的信任、网络效应。
十、总结
10.1 不会过时的三个问题
模型每几个月迭代一次，具体的 API、产品和榜单都会翻篇，但以下三个问题不会过时：
- Agent 能看到什么？ — 上下文的设计与管理
- Agent 能做什么？ — 工具的定义与调度
- 如何验证 Agent 做得对不对？ — 评估与纠正机制
这三个问题描述的不是某个模型的用法，而是一个智能系统与世界交互的基本方式。
10.2 核心 takeaways
- Agent = LLM + 上下文 + 工具 — 理解这个公式，就掌握了构建 Agent 的基础
- Harness 是核心竞争力 — 当模型能力趋同，竞争优势在模型之外的工程实践
- 从简单开始 — 最成功的实现往往不是使用复杂的框架，而是采用简单、可组合的模式
- 评估驱动改进 — 没有评估，就无法判断 Agent 是进步还是退化
- 模型与 Harness 共同演进 — 这条飞轮是这个时代最深的一条护城河