LLM Agent 技术演化史：从 Prompt 到 Harness Engineering#

1. 阶段背景#

2022 年末到 2023 年初，行业最关注的是如何让模型输出更好。ChatGPT 发布后，用户第一次感受到一个通用语言模型可以完成写作、总结、解释代码、翻译、头脑风暴、问答等大量任务。

但这一代系统主要运行在聊天窗口里。它的输入是用户文本，输出也是文本。它能告诉用户“应该怎么做”，但不能替用户完成真实动作。

这一阶段的核心矛盾是：

模型能生成语言，但缺少外部世界。

它没有实时知识，没有企业内部数据，没有工具执行能力，也没有跨任务状态。

2. Prompt Engineering 的技术尝试#

Prompt Engineering 的本质，是用自然语言约束模型的输出空间。它并不会把模型参数中没有的事实直接变出来，但可以让模型更稳定地进入某种任务、角色、格式和推理路径。

1
请总结这篇文章。
2
请把这段话翻译成英文。
3
请写一个 Python 函数。

1
你是一名资深产品经理。
2
你是一名法律顾问。
3
你是一名代码审查专家。

1
flowchart TD
2
    A["用户任务"] --> B["Prompt 约束"]
3
    B --> C["角色"]
4
    B --> D["示例"]
5
    B --> E["格式"]
6
    B --> F["推理步骤"]
7
    C --> G["模型输出"]
8
    D --> G
9
    E --> G
10
    F --> G

3. 暴露的问题#

第一，Prompt 不能补事实。如果模型不知道最新信息，Prompt 写得再好也没有稳定依据。

第二，Prompt 不能执行动作。它可以让模型写代码，但不能保证代码运行；可以让模型写 SQL，但不能保证数据库查询正确；可以让模型生成计划，但不能真正执行计划。

第三，Prompt 很脆弱。同一个任务，换一种说法，结果可能不同。提示词模板看起来有效，但在不同模型、不同上下文、不同用户输入下容易失效。

第四，Prompt 工程出现泡沫。早期行业把很多模板技巧包装成长期壁垒。后来模型指令遵循能力增强，系统提示、产品交互、结构化输出和工具调用能力成熟，单纯“卖提示词模板”的价值迅速下降。

4. 这一阶段的历史意义#

Prompt 时代的意义不在于提示词模板本身，而在于它定义了 LLM Agent 的第一个工程问题：如何把人类意图稳定地传递给模型。

这一阶段留下的经验后来并未消失。系统提示、开发者消息、角色约束、输出格式、few-shot 示例、任务模板，今天仍然是 Agent 系统的重要组成部分。只是它们从“全部能力来源”，退回到了更合理的位置：语言控制层。

1. 阶段背景#

当模型具备较强语言能力后，行业很快遇到两个问题：

• 模型不知道最新或私有信息；
• 模型不能执行真实动作。

于是第二阶段的主导工程问题变成：如何让模型接触外部世界。

这个阶段包含两条并行路线：RAG 让模型获得外部知识，Tool Use 让模型执行外部动作。

2. RAG：把外部知识接入上下文#

RAG 的基本思路是：先把文档切块、向量化、存入检索系统；用户提问时，系统检索相关片段，把片段放入上下文，再让模型回答。

1
flowchart TD
2
    A["外部文档"] --> B["切块"]
3
    B --> C["向量化"]
4
    C --> D["索引 / 向量库"]
5
    Q["用户问题"] --> E["检索"]
6
    D --> E
7
    E --> F["相关片段"]
8
    F --> G["注入上下文"]
9
    G --> H["模型回答"]

RAG 解决了第一代对话模型的知识断裂问题。企业规章、产品文档、代码库说明、研究论文、客服知识库，都可以通过检索进入模型上下文。

但 RAG 也暴露出一批问题：

后续优化包括 hybrid search、rerank、结构化元数据、引用来源、source pointer、contextual retrieval、按权限过滤等。RAG 的本质没有过时，但它从“一个向量库方案”变成了更完整的数据与上下文工程。

3. Tool Use：从文本建议到真实动作#

Tool Use 的核心，是让模型输出结构化调用，由外部运行时执行真实动作。

从早期 Plugins、Function Calling，到 Toolformer、MRKL、后来的结构化输出和原生工具调用，行业逐步形成了一个基本范式：

1
sequenceDiagram
2
    participant U as User
3
    participant M as LLM
4
    participant R as Runtime
5
    participant T as Tool
6

7
    U->>M: 提出任务
8
    M->>R: 生成工具调用
9
    R->>T: 执行工具
10
    T-->>R: 返回结果
11
    R-->>M: 注入观察结果
12
    M-->>U: 继续推理或最终回答

工具调用让模型第一次从“建议者”变成“执行者”。模型可以查询天气、查数据库、调用企业 API、运行代码、读取文件、搜索网页。

但 Tool Use 也很快暴露出风险：

• 工具选择错误；
• 参数生成错误；
• 工具结果解释错误；
• 缺少权限边界；
• 工具输出过长，污染上下文；
• 工具失败后缺少恢复策略。

因此，工具调用必须逐步引入 JSON Schema、工具白名单、参数校验、权限分级、结果摘要、错误反馈和人类确认。

4. AutoGPT：第一次自主 Agent 狂热与幻灭#

RAG 和 Tool Use 让行业看到一个更激进的可能：既然模型能读资料、能调工具，能不能给它一个大目标，让它自己循环完成任务？

AutoGPT 代表了这波狂热。它尝试让模型自己生成任务队列，执行工具，写入文件，评估进展，再生成下一步行动。

1
flowchart TD
2
    A["长期目标"] --> B["拆分任务"]
3
    B --> C["选择工具"]
4
    C --> D["执行动作"]
5
    D --> E["观察结果"]
6
    E --> F["更新记忆"]
7
    F --> G{"认为完成了吗"}
8
    G -- "否" --> B
9
    G -- "是" --> H["输出结果"]

它的演示效果很强，但幻灭也很快。根本问题在于开环控制：缺少可靠状态约束、终止条件、任务预算、验证器和人机协作节点。模型可能在错误方向上不断循环，也可能为了简单任务消耗大量调用成本。

AutoGPT 的历史意义，是用失败证明了一个重要原则：

工具调用加循环，不等于生产级 Agent。

从这里开始，行业转向更工程化的工作流编排。

1. 阶段背景#

AutoGPT 之后，行业逐渐放弃“给模型一个目标，让它自由发挥”的天真假设。真正可用的 Agent 必须有状态管理、计划约束、工具边界、评估机制和人工介入。

这一阶段的核心工程问题是：

如何把模型的推理和行动放进可控流程里。

2. ReAct：推理与行动交替#

ReAct 代表了一个关键范式：Reasoning + Acting。模型先分析当前状态，再调用工具，读取观察结果后继续推理。

1
flowchart TD
2
    A["任务"] --> B["Reason<br/>分析状态"]
3
    B --> C["Act<br/>调用工具"]
4
    C --> D["Observe<br/>读取结果"]
5
    D --> E{"是否完成"}
6
    E -- "否" --> B
7
    E -- "是" --> F["交付"]

这比 AutoGPT 的自由循环更可控，因为每一步都围绕当前观察结果推进，也更容易插入日志、预算、检查点和人类确认。

3. Agentic Workflow 的几类模式#

工程实践中，Agentic Workflow 逐渐沉淀出几类模式。

这类工作流的共同点，是把模型放进人类设计的控制结构中。可靠性逐步转向依赖规划、执行、观察、评估和修正的闭环。

1
flowchart TD
2
    A["复杂目标"] --> B["Planner"]
3
    B --> C["Executor"]
4
    C --> D["Tool / Environment"]
5
    D --> E["Observation"]
6
    E --> F["Evaluator"]
7
    F --> G{"通过"}
8
    G -- "否" --> B
9
    G -- "是" --> H["交付"]

4. Context Engineering：信息组织成为核心能力#

随着工作流变长，Context Engineering 变成核心问题。

早期做法是把尽可能多的信息塞进上下文。后来大家发现，上下文窗口越长，成本、延迟和注意力稀释越明显；无关信息也会污染模型判断。Context Engineering 的目标，是在尽可能少的 token 中提供足够支撑期望输出的信息。

它解决四类问题：

• 给什么信息；
• 什么时候给；
• 以什么结构给；
• 旧信息如何压缩、保存和恢复。

常见技术包括长上下文、RAG 2.0、上下文压缩、记忆分层、工具说明检索、源材料指针、对话 compaction。

1
flowchart TD
2
    A["信息全集"] --> B["检索"]
3
    A --> C["过滤"]
4
    A --> D["排序"]
5
    B --> E["候选上下文"]
6
    C --> E
7
    D --> E
8
    E --> F["压缩"]
9
    F --> G["当前上下文"]
10
    G --> H["模型推理"]
11
    H --> I{"值得保存"}
12
    I -- "是" --> J["长期记忆"]
13
    I -- "否" --> K["丢弃或保留在短期上下文"]

长期记忆更像硬盘，当前上下文更像内存。Agent 不能把所有历史都放进内存，只能在需要时从记忆、文件、日志和检索系统中恢复相关片段。

5. Reasoning Models：推理能力开始内化#

随着 reasoning models 出现，部分原先依赖 Prompt 技巧的推理能力开始内化到模型本身。模型可以花更多计算做复杂推理，也能更稳定地处理多步任务。

这并没有让 Agent 工程消失。原因很简单：推理能力增强，通常会让模型承担更复杂、更长链路、更高风险的任务。任务难度上升后，工具边界、上下文控制、里程碑检查、评估和回滚仍然必需。

Reasoning Models 对 Agent 的影响主要有三点：

• 复杂规划能力提高；
• 工具调用前的分析更细；
• 任务成本、延迟和执行风险也随之上升。

因此，模型路由、预算控制、里程碑检查和人类确认变得更重要。

6. 这一阶段的历史意义#

这一阶段把 Agent 从“演示很惊艳”推进到“流程可管理”。它让行业认识到，Agent 的可靠性来自工程结构，而不是单纯来自模型自由发挥。

1. 阶段背景#

当工作流编排逐渐成熟后，新的问题出现了：工具和环境太碎片化。

每个 Agent 都要接不同工具，每个工具都要适配不同 Agent。开发者还要面对浏览器、IDE、终端、文件系统、企业后台、没有 API 的网页和各种 GUI 软件。

这一阶段的核心工程问题是：

Agent 如何标准化连接外部工具，并进入真实工作环境。

2. MCP：从工具孤岛到协议层#

MCP 的目标是降低工具接入复杂度。过去是 M 个 Agent 客户端适配 N 个工具，复杂度接近 M 乘 N；协议化后，每个工具实现一次 MCP Server，支持 MCP 的客户端即可调用，复杂度向 M 加 N 收敛。

1
flowchart TD
2
    subgraph Before["协议化之前"]
3
        A1["Agent A"] --> T1["Tool 1"]
4
        A1 --> T2["Tool 2"]
5
        A2["Agent B"] --> T1
6
        A2 --> T2
7
    end
8

9
    subgraph After["协议化之后"]
10
        C1["Agent A"] --> MCP["MCP"]
11
        C2["Agent B"] --> MCP
12
        MCP --> S1["MCP Server 1"]
13
        MCP --> S2["MCP Server 2"]
14
    end

MCP 这类协议的意义不只是工具数量增加，更在于它把工具连接从产品私有能力推向生态基础设施。

但协议标准化不等于安全。MCP Server 质量、权限模型、数据泄露、供应链攻击、工具输出污染，仍然需要产品和运行时系统处理。

3. Computer Use：从 API 世界进入 GUI 世界#

Tool Use 主要连接 API，但现实世界里大量软件没有稳定 API。人类每天使用浏览器、表单、后台系统、IDE、网页按钮和桌面应用。Computer Use 的意义，是让 Agent 可以看屏幕、点击、输入、读取视觉反馈。

1
flowchart LR
2
    A["API Tool Use"] --> B["结构化接口"]
3
    C["Computer Use"] --> D["屏幕"]
4
    D --> E["鼠标"]
5
    D --> F["键盘"]
6
    D --> G["浏览器 / GUI"]

这扩大了 Agent 的行动空间，也引入了新风险：

• GUI 状态不稳定；
• 坐标和元素识别脆弱；
• 页面变化导致操作失效；
• 模型可能误读视觉信息；
• 高风险按钮需要确认；
• 操作后的结果必须验证。

所以 Computer Use 必须配合虚拟浏览器、沙箱、截图审查、DOM 辅助信息、动作确认和状态验证。

4. Coding Agent：软件工程最先落地#

Coding Agent 是 Agent 最先大规模落地的场景之一。原因很明确：

• 代码是文本，适合 LLM 处理；
• 开发环境有文件、终端、测试、git、CI 等可观测工具；
• 成功与失败相对容易验证；
• 开发者能审查 diff；
• 工程任务天然适合规划、执行、测试和回滚。

从 Copilot 式补全，到 IDE Agent、CLI Agent、PR Agent，Agentic Coding 的形态逐渐变化：

但 Coding Agent 也暴露出典型问题：代码能跑不代表架构正确；测试覆盖不足会放大幻觉；Agent 可能破坏安全边界；大型仓库上下文巨大；生成速度带来的主观提速可能掩盖真实交付成本。

因此，Coding Agent 的成熟依赖测试、diff review、sandbox、权限控制、上下文检索、CI 验证和人工审查。

5. 这一阶段的历史意义#

这一阶段让 Agent 真正进入工作环境。协议层解决工具连接问题，Computer Use 解决 GUI 操作问题，Coding Agent 证明 Agent 可以在一个可观测、可验证、可回滚的专业场景中产生真实生产力。

它也说明一件事：Agent 越接近真实工作，越需要治理。

1. 阶段背景#

前几个阶段让 Agent 会说、会查、会调工具、会编排工作流、会进入软件环境。下一步的问题是：如何让 Agent 长期存在、持续跟进目标，并在风险可控的条件下运行。

这一阶段包含 Skills、Memory、Tasks、Heartbeat、Background Agent 和 Harness Engineering。它们解决的是同一个更大的问题：

如何把概率模型包装成可运行、可治理、可审计、可恢复的系统。

2. Skills：从会用工具到会按组织方法做事#

Tool Use 解决“能调用什么工具”。Skills 解决“如何专业地使用工具”。

一个 Skill 通常不只是 API 描述，还可以包含：

• 领域知识；
• 操作流程；
• 脚本；
• 模板；
• 示例；
• 注意事项；
• 验证方法；
• 输出规范。

例如，处理 Excel 是一个 Skill，制作 PPT 是一个 Skill，前端视觉审查是一个 Skill，安全代码审查也是一个 Skill。Agent 可以按任务加载专业方法，减少从零推理的成本。

Skills 的关键工程思想是渐进式披露：

1
flowchart TD
2
    A["任务"] --> B["技能索引"]
3
    B --> C{"命中技能"}
4
    C -- "否" --> D["普通推理"]
5
    C -- "是" --> E["加载技能说明"]
6
    E --> F{"需要资源"}
7
    F -- "是" --> G["加载脚本 / 模板 / 示例"]
8
    F -- "否" --> H["执行"]
9
    G --> H

这样可以避免把全部工具说明、领域文档、脚本模板一次性塞进上下文。

Skills 也带来供应链风险。Skill 是 Agent 会阅读并遵循的文本和脚本，因此恶意 Skill 可以通过提示注入、脚本执行、数据外传改变 Agent 行为。未来 Skills 需要版本管理、签名、权限声明、来源审查和运行隔离。

3. Memory、Tasks 与 Heartbeat：Agent 获得长期存在感#

Memory 让 Agent 跨会话保存用户偏好、项目约定、历史决策和失败经验。Tasks 让 Agent 可以管理待办事项。Heartbeat 让 Agent 可以按时间被唤醒，检查是否需要行动。

这三者组合后，Agent 从一次性响应工具，变成有长期状态的参与者。

1
flowchart TD
2
    A["用户目标"] --> B["任务状态"]
3
    B --> C["定期唤醒"]
4
    C --> D["读取记忆"]
5
    D --> E["检查环境"]
6
    E --> F{"需要行动"}
7
    F -- "否" --> G["保持安静"]
8
    F -- "是" --> H["执行或提醒"]
9
    H --> I["更新记忆和任务状态"]
10
    I --> C

但长期存在也带来长期风险：

• 长期权限风险；
• 记忆污染；
• 过期信息持续影响判断；
• 频繁提醒造成打扰；
• 背景任务失败后责任边界不清；
• 用户忘记曾授权某个 Agent。

因此，长期运行 Agent 需要权限过期、记忆审查、通知策略、审计日志、任务取消、运行摘要和人工确认。

4. Harness Engineering：把概率模型变成稳定系统#

Harness Engineering 是这一阶段的最高层抽象。它是一组围绕模型建立的运行时、治理和恢复机制。

可以把 Agent 系统拆成几层：

1
flowchart TD
2
    A["LLM 推理核心"] --> B["上下文管理"]
3
    B --> C["工具系统"]
4
    C --> D["工作流 / 状态机"]
5
    D --> E["权限与安全"]
6
    E --> F["评估与观测"]
7
    F --> G["失败恢复"]
8
    G --> H["长期运行"]

Harness 的目标是把随机生成系统变成稳定软件系统。它至少包含以下能力：

5. Harness 的六层工程结构#

生产级 Agent 通常需要六层结构。

第一层是信息边界层。它决定哪些信息进入模型、以什么优先级进入、哪些内容是全局规则、哪些内容是用户偏好、哪些内容是项目级约束。

第二层是工具系统。工具需要统一规范，包括输入输出 Schema、读写属性、是否可并发、是否有破坏性、是否需要确认、失败时如何返回错误。

第三层是编排运行层。复杂任务需要规划、拆分、并发、子 Agent、状态机和中途转向能力。

第四层是状态与记忆层。Agent 需要区分短期上下文和长期记忆。短期上下文用于当前推理，长期记忆用于跨会话恢复。

第五层是评估与观测层。Agent 完成任务后需要自检，关键节点需要里程碑检查，最终交付需要测试、评估和审查。

第六层是约束与失败恢复层。失败后要能重试、注入错误原因、回滚状态、切换路径或请求人工介入。

1
flowchart TD
2
    A["生产级 Agent"]
3
    A --> L1["1. 信息边界"]
4
    A --> L2["2. 工具系统"]
5
    A --> L3["3. 编排运行"]
6
    A --> L4["4. 状态与记忆"]
7
    A --> L5["5. 评估与观测"]
8
    A --> L6["6. 约束与失败恢复"]

6. OpenClaw / OpenCloud 类框架的案例意义#

以 OpenClaw、OpenCloud 这类 Agent 框架为例，可以看到 Harness 如何落地为一组具体机制：

• 用本地文件系统保存身份、偏好、项目规则和安全边界；
• 把长期记忆从上下文窗口里拆出去；
• 用 Skill 和 MCP 分别解决专业方法与工具连接；
• 对工具调用设置读写属性、破坏性确认和并发控制；
• 对长上下文做压缩、折叠、摘要和回源；
• 失败后通过重试、回滚、路线切换和人工确认恢复。

1
flowchart TD
2
    U["用户目标"] --> I["意图捕获"]
3
    I --> P["任务拆解"]
4
    P --> C["上下文选择"]
5
    C --> M["记忆检索"]
6
    C --> S["Skill 加载"]
7
    M --> T["工具选择"]
8
    S --> T
9
    T --> G{"安全门"}
10
    G -- "低风险" --> X["自动执行"]
11
    G -- "高风险" --> H["人工确认"]
12
    H --> X
13
    X --> O["观测结果"]
14
    O --> E{"验证通过"}
15
    E -- "否" --> R["重试 / 回滚 / 改路"]
16
    R --> P
17
    E -- "是" --> D["交付并更新状态"]

这类案例的价值，不在于某一个单点功能，而在于把长期运行 Agent 所需的多个工程部件组织到一起。

7. 这一阶段的历史意义#

Agent 成熟的标志，是从“会做”走向“可治理地做”。随着 Agent 获得长期记忆、工具权限、后台时间和执行能力，安全、审计、恢复、权限和责任边界变成系统中心。