Agent 不是模型加工具，而是一类新的系统工程对象

我越来越不把 Agent 简单理解成 LLM + Prompt + Tools。

这个公式当然方便，也足够解释早期 demo。但一旦你真的开始做长时间运行、会调工具、会改状态、还会在真实环境里留下副作用的系统，它就显得太薄了。

我现在更愿意把 Agent 定义成：

弱可验证、部分可观测、开放环境中的长程闭环决策系统。

它的基本循环并不神秘：

观察环境 → 构造当前认知 → 生成决策 → 执行行动 → 获得反馈 → 更新状态

真正难的地方，也不是“模型会不会犯错”这么笼统。更麻烦的是：任务目标通常不完全明确，环境状态无法完整获得，执行过程跨很多步，最终效果又只能靠不完善的代理指标来评价。你没法只用“答案对不对”来打分，也很难指望它像分类准确率那样，压成一个干净的单一指标。

所以我才会越来越觉得，Agent 首先不是一个模型问题，而是一类新的系统工程对象。

Prompt、Context、Harness，其实是同一闭环里的不同控制位置

从模型接口上看，Context 最终还是会变成输入 token，广义上当然都属于 Prompt。但工程上如果不区分它们，后面几乎一定调不好。

因为它们的来源、生命周期和故障方式完全不同。

Prompt 更像策略先验。它规定 Agent 面对某类情况时，应该依据什么原则决策：任务优先级、风险边界、工具使用原则、什么时候验证、什么时候问人、什么时候停。它回答的是：面对这类情况，应该怎么想。

Context 则是当前认知状态。历史对话、Memory、检索结果、工具返回、任务进度、用户和环境状态，都会进这里。它回答的不是“世界是什么”，而是：Agent 当前以为自己知道什么。

这一点特别重要。Context 不是现实世界本身，而是系统构造出来的世界表示。所以它天然可能缺失、过时、冲突，也可能在压缩里丢掉关键信息。

Harness 负责的是感知、行动与状态转移机制。信息从哪里来、哪些信息进入 Context、模型能调什么工具、工具怎么执行、状态怎么保存、失败怎么恢复、结果怎么验证、任务如何继续或结束，这些都属于它。它回答的是：信息和行动如何在整个系统中流动。

如果压缩成一句话，我会这样说：

Prompt 控制决策原则，Context 决定当前认知，Harness 控制感知、行动和状态转移。

Agent 的表现，从来不是模型单独决定的，而是模型和这三者一起作用的结果。

Agent 优化的核心，不是“调 Prompt”，而是找对干预位置

一个 badcase 看起来很像“模型不行”，但真正成因可能完全不在模型层。

它可能来自：

• 任务或产品定义本身就不对
• Prompt 规则不合理
• Context 缺失或错误
• Memory 污染
• 工具描述不清楚
• 工具本身执行失败
• Harness 状态管理出错
• 模型能力不足
• 评价器判断错误
• 外部环境波动

所以真正重要的问题，通常不是：

怎么改 Prompt，才能让这个 case 通过？

而是：

这个失败发生在哪一层，应该改哪一层？

我觉得成熟的 Agent 工程，核心就三件事：

1. 系统辨识
2. 干预位置选择
3. 在效果、成本、延迟和可靠性之间做资源配置

一个人的价值，也不是“最会写 Prompt”，而是知道：

• 什么时候改 Prompt
• 什么时候补 Context
• 什么时候加 Workflow
• 什么时候修工具
• 什么时候换更强模型
• 什么时候才值得做 SFT 或 RL
• 什么时候问题其实来自产品定义和评价标准

如果分不清干预位置，你很容易把所有失败都砸回模型，然后用训练去补偿本不该由模型承担的错误。

评价对象不该只是最终结果，而是完整轨迹

如果只看最终答案，很多完全不同的故障，最后都会表现成同一种失败。

所以我越来越相信，真正的评价对象应该是完整执行链：

目标定义 → 信息获取 → Context 构造 → 模型决策 → 工具执行 → 状态更新 → 结果验证

未来成熟的 Agent 评价体系，大概不会只剩一个总分，而会同时看：

• 最终任务结果
• 决策和工具调用过程
• 环境最终状态
• 成本与延迟
• 错误恢复
• 人工介入
• 安全与完整性
• 是否存在 reward hacking

这里真正要提升的，不是“指标数量”，而是可辨识性：

当 Agent 的表现发生变化时，我们能不能知道究竟是什么造成的？

没有可辨识性，所谓优化就很容易变成玄学调参。

自进化首先不是算法问题，而是实验基础设施问题

Hermes 这类系统已经展示了不少有意思的方向：从执行轨迹里生成 Memory，提炼 Skill，优化 Prompt，甚至导出训练或强化学习数据。这些都很值得看。

但我并不觉得，这就证明“自进化”问题已经解决了。

因为系统在自动修改自己之前，必须先回答更基础的问题：

• 为什么失败
• 应该改哪一层
• 修改后是否真的更好
• 提升是否只是环境变化带来的假象
• 是否对评测集过拟合
• 是否损害了其他能力

所以可靠自进化的前提，其实很朴素：

Agent 的运行状态必须可观察、可版本化、可回放、可比较、可回滚。

没有这些能力，系统只能自动“变化”，不能证明自己是在“进化”。

Agent 需要一种类似 Git 的完整状态版本系统

传统 Git 保存的是代码文件。但 Agent 的行为，取决于远比代码更多的东西。

一个完整的 Agent 版本，至少应该包括：

• 模型及推理配置
• Prompt 和 Skill
• Memory
• Context 构造逻辑
• Harness 代码与配置
• 工具 Schema 和版本
• 评价器版本
• 环境和任务状态

可以把这理解成一个 Agent Commit：模型、Prompt、Context、Harness、Tools、State、Evaluator 一起被版本化。

但只有快照还不够。你还得记录完整事件流：

• 用户输入
• Context 来源
• 最终发送给模型的消息
• 模型决策
• 工具调用
• 工具返回
• 状态变化
• 验证结果

所以我现在越来越觉得，一个可靠的 Agent 基础设施，更接近：

Git + Event Sourcing + Distributed Tracing + Replay Simulator

不是哪一个单独的能力，而是这些东西合在一起，才可能让 Agent 变得可审计、可比较、可改进。

回放追求的不是 100% 复制现实，而是因果可比较

真实环境永远无法被百分之百恢复。

模型有随机性，工具和外部数据会变，历史状态也可能缺失。所以回放的目标，不该是逐 token 得到相同输出。

更现实的目标是：

尽可能固定主要条件，只改变需要研究的组件，从而判断它是否真正产生了改善。

至少可以区分几种回放：

1. 模型决策回放：冻结 Context 和工具结果，只比较模型或 Prompt
2. Harness 回放：重新构造 Context，但使用冻结的历史工具返回
3. 环境模拟回放：在 Mock 或数字孪生环境中重新执行工具
4. 真实环境 Shadow Replay：候选版本在真实流量上影子运行，不影响实际用户

相应地，还需要一个“回放保真度”的概念：哪些状态被恢复了，哪些缺失了，这些缺失又可能怎样影响结论。

没有保真度意识的回放，很容易给人一种“好像验证过了”的错觉。

Agent 同时是业务执行系统，也是学习数据生产系统

一个成熟 Agent，至少应该同时跑两个循环。

一个是业务执行循环：

任务 → 决策 → 工具执行 → 业务结果

另一个是能力学习循环：

运行轨迹 → 失败发现 → 成因归类 → 干预选择 → 评测验证 → 系统升级

真正的数据飞轮，不是简单保存日志，而是把真实轨迹转化成：

• 有明确任务定义的数据
• 有完整状态的数据
• 有失败成因的数据
• 有验证结果的数据
• 有干预标签的数据

只有经过归因后，剩下的“模型能力残差”，才适合进入 SFT、偏好优化或强化学习。

否则，你直接拿 badcase 去训模型，可能只是在让模型补偿错误的工具、Context 或产品设计。

早期智能助手和今天的 Agent，其实是同一问题的不同阶段

Siri、小爱同学、Cortana、Alexa、小冰，其实已经包含了很多今天 Agent 的元素：Intent、Slot、Dialogue State、Skills、Workflow、Memory、Tool Execution、用户画像、监控和 badcase 分析。

它们的核心范式是：

先定义有限的意图、状态和能力，再把用户语言映射进去。

这是一种封闭世界、Schema First 的 Agent。

LLM Agent 的变化在于：通用模型开始同时承担意图理解、状态解释、规划、工具选择和语言生成，系统因此从封闭意图空间走向开放任务空间。

但现代 Agent 并没有淘汰旧系统的工程经验，反而需要重新吸收它们：状态机、权限、工具 Schema、规则校验、降级、人工接管、日志、仿真、回放、安全边界。

历史演化不是“规则系统被大模型彻底替代”，而更像是：

模块化规则系统 → 大模型打开任务边界 → 围绕大模型重建结构化 Harness

开放能力打开了空间，结构化 harness 又把空间重新收成可工程化的系统。

通用框架和业务定制层，必须明确分开

通用基础设施当然可以提供很多东西：

• Agent Loop
• 模型路由
• Tool 和 Skill 协议
• Context Store
• Memory
• Trace
• Snapshot
• Replay
• 权限
• 评测框架
• Champion–Challenger
• 数据导出

但业务必须自己定义：

• 世界中有哪些关键状态
• 哪些状态与任务相关
• Agent 能观察什么
• 能采取什么行动
• 什么算完成
• 哪些错误不可接受
• 哪些动作必须确认
• 如何建立真实环境模拟
• 如何获得用户信任

所以真正的行业壁垒，通常不是再实现一个通用 Agent Loop，而是：

把具体业务世界建模成一个 Agent 可以感知、行动、验证、回放和学习的环境。

在 Code Agent 很强的今天，人的价值其实在迁移

Code Agent 显著降低了代码实现成本，但没有降低下面这些问题的难度：

• 应该构造什么系统
• 如何定义业务状态
• 如何设计任务契约
• 如何判断成功和失败
• 如何做实验
• 如何定位成因
• 如何控制风险
• 如何建立可信的数据闭环

因此，今天构建 Agent 系统最稀缺的能力，不再只是手写代码，而更接近这些：

1. 任务与世界建模：把模糊业务转化成状态、观察、动作、约束和完成条件
2. 评价与实验设计：设计状态化测试、Replay、消融、Shadow Test 和可信 Grader
3. 系统可观测与可回放：理解 Event Sourcing、Trace、版本化、幂等、重试和状态恢复
4. 模型边界与干预选择：判断问题该通过 Prompt、Context、Harness、工具、模型还是产品解决
5. 工具和接口设计：让工具具备清楚语义、边界、前置条件、错误反馈和安全性
6. 产品和风险判断：明确哪些任务可自动化，哪些必须确认、降级或人工接管
7. 驾驭 Code Agent：把需求、架构、不变量和验收条件表达清楚，让它实现，并验证正确性

代码当然还在写。但真正决定系统能不能成立的，越来越不是“你会不会把循环写出来”，而是“你有没有把世界、任务、评价和风险讲清楚”。

我现在暂时接受的定义

如果一定要把前面这些压成一个定义，我会这样说：

Agent Engineering 是围绕弱可验证、部分可观测、开放环境中的长程任务，构建可感知、可行动、可验证、可回放和可持续改进的闭环决策系统的工程方法。

其中：

• Prompt 提供策略先验
• Context 表达当前认知
• Harness 负责感知、行动与状态转移
• Tool 连接外部世界
• Evaluation 判断结果与过程
• Replay 提供可比较实验
• Attribution 决定应该改哪一层
• Learning Pipeline 把真实轨迹转成系统和模型升级的数据

而可靠自进化的前提，也不是“先让 Agent 自动修改自己”，而是：

先让 Agent 的世界能够被保存，让历史能够被回放，让修改能够被归因，让进化能够被验证。

最终，Agent 不只是一个完成业务任务的产品形态，也是一套把真实业务运行，转化成能力改进和模型训练资产的基础设施。