第 1 章 Agent 的本质 —— 模型即智能体

Agent 是经过训练的模型在受控环境中自主执行动作的系统，不是 prompt 管道。Harness 是模型的操作环境，不是智能本身。

---

1.1 从 DQN 到 LLM Agent：智能体的历史脉络

"智能体"（Agent）并非 LLM 时代的发明。从强化学习到大语言模型，Agent 的核心结构始终未变：trained model + environment + action interface。

关键里程碑

年份	项目	模型	环境	Action Interface
2013	DeepMind DQN	CNN + Q-Learning	Atari 游戏	离散动作（上下左右开火）
2019	OpenAI Five	LSTM + PPO	Dota 2	170K+ 维度的动作空间
2019	AlphaStar	Transformer + 多 Agent 联赛	StarCraft II	结构化动作序列
2019	绝悟 (Tencent)	LSTM + 自博弈	王者荣耀	实时连续动作
2024-2025	LLM Agents (Claude Code, Codex, etc.)	LLM (GPT-4, Claude, etc.)	操作系统 / 文件系统 / 浏览器	Tool Calling (Function Call)

这张表的共同结构值得注意：

1. 模型承担决策——DQN 的 CNN 决定按哪个键，LLM Agent 的 Claude 决定调哪个工具。
2. 环境提供反馈——Atari 返回像素和分数，文件系统返回文件内容和命令输出。
3. 动作接口定义边界——DQN 只有 18 个离散动作，LLM Agent 的动作空间是所有注册工具的参数组合。

LLM Agent 与 RL Agent 的核心差异在于训练范式：RL Agent 在特定环境中从零训练到收敛；LLM Agent 的"训练"在预训练和 RLHF 阶段已经完成，部署时的 harness 只负责把模型的文本输出转化为真实动作。但从系统架构看，它们是同一个东西：循环调用模型，执行动作，观察反馈，直到终止条件满足。

Agent Loop 的最小实现

Agent Loop 的核心可以用不到 30 行 Python 代码展示：

# Agent Loop 最小实现（Python）
def agent_loop(messages: list):
    while True:
        response = client.messages.create(
            model=MODEL, system=SYSTEM, messages=messages,
            tools=TOOLS, max_tokens=8000,
        )
        messages.append({"role": "assistant", "content": response.content})
        if response.stop_reason != "tool_use":
            return
        results = []
        for block in response.content:
            if block.type == "tool_use":
                output = run_bash(block.input["command"])
                results.append({"type": "tool_result", "tool_use_id": block.id,
                                "content": output})
        messages.append({"role": "user", "content": results})

终止条件是 stop_reason != "tool_use" —— 模型不再调用工具时循环结束。这个条件从 DQN 到 LLM Agent 从未改变，只是表达形式不同：DQN 用 episode done flag，LLM Agent 用 stop_reason。

---

1.2 Agent vs Workflow：本质区别

Workflow = 程序员编排的固定流程

Workflow 的每一步由开发者预先定义。遇到什么条件走哪个分支，全部写死在代码里：

步骤1：搜索相关资料
步骤2：总结资料
步骤3：生成大纲
步骤4：撰写正文
步骤5：润色

这是 GOFAI（Good Old-Fashioned AI）的复辟——用规则系统假装智能。可预测、可审计、可复现，但天花板等于设计者的想象力上限。设计者没预见到的情况，Workflow 处理不了。

Agent = 模型自主决策的动态执行

Agent 不预设流程。每一步由模型根据当前上下文自行判断：

Agent 收到任务后：
1. [思考] 需要先了解项目结构
2. [行动] 调用 list_directory 工具
3. [观察] 发现是 TypeScript 项目
4. [思考] 需要看具体文件
5. [行动] 调用 read_file 工具
6. [观察] 发现代码质量问题
7. [回复] 输出分析报告

关键区别：第 3 步的结果决定第 4 步做什么。如果第 3 步发现是 Rust 项目，Agent 会走完全不同的路径。Workflow 做不到这一点——除非开发者预先写了所有语言的分支。

"One Loop & Bash is All You Need"

Agent 社区中有一个尖锐的判断：

"One loop & Bash is all you need"

这句话的含义是：一个工具 + 一个循环就构成了 Agent 的全部。剩下的一切——多工具注册、权限控制、上下文管理——都是在这个循环之上的增量叠加，而不是结构性改变。

相比之下，那些用复杂 DAG（有向无环图）编排多步 prompt 的系统，本质上是在用程序逻辑替代模型决策。主流 Agent 实现的经验表明：添加工具只需要添加一个 handler，循环本身不变（Agent loop: Unchanged）。这正是 Agent 和 Workflow 的分界线：Agent 的控制流由模型驱动，Workflow 的控制流由代码驱动。

什么时候用 Workflow 更好

Agent 不是万能的。当任务流程完全确定、不需要动态决策时，Workflow 更可靠：

• 银行转账流程：验证身份 → 检查余额 → 执行转账 → 发送通知
• CI/CD 流水线：编译 → 测试 → 打包 → 部署
• 表单处理：校验输入 → 存库 → 返回确认

这些场景的每一步都是确定的，让 LLM 自主决策只会引入不必要的随机性和成本。

---

1.3 Harness 的定义与三代演进

Harness 的定义

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions

Harness 是模型与真实世界之间的全部中间层。它不是智能本身——智能在模型里。Harness 决定的是：模型能看到什么（Knowledge/Observation）、能做什么（Tools/Action Interfaces）、不能做什么（Permissions）。

OpenAI 的 Ryan Lopopolo 在《Harness Engineering》中给出的定义："围绕 AI Agent 构建的约束、反馈与控制系统。核心理念是：不优化模型本身的智力，而是优化模型运行的'环境'。"

三代演进

graph LR
    P1["第一代<br/>Prompt Engineering<br/>教模型怎么说话"]
    P2["第二代<br/>Context Engineering<br/>教模型怎么看信息"]
    P3["第三代<br/>Harness Engineering<br/>构建自治环境"]
    P1 --> P2 --> P3

第一代：Prompt Engineering（提示词工程）

核心问题：如何给模型写一条好的指令。交互模式是一问一答。优化目标是单次对话的输出质量。典型产物是各种 prompt 模板。

第二代：Context Engineering（上下文工程）

核心问题：如何给模型喂正确的信息。技术手段包括 RAG、KV-cache 优化、上下文压缩、渐进式披露。交互模式是"给背景资料 → 模型生成内容"。Manus 团队在这方面积累了大量实践经验，他们提出的六条原则（围绕 KV-cache 设计、用 masking 代替移除工具、文件系统作外部记忆、复述操控注意力、保留错误记录、打破 few-shot 陷阱）是 Context Engineering 的工业级实践。

第三代：Harness Engineering（驾驭工程）

核心问题：如何构建一个完整的自治环境，让模型在其中安全、高效地长期运行。交互模式变成"人造环境，AI 在里面跑"。不再执着于单次对话的质量，而是建立一整套系统来约束、引导和验证 Agent 的自主行为。

Harness 的五大核心组件

根据 Harness Engineering 文献综合，一个完整的 Harness 系统包含：

1. 结构化知识与渐进式披露

把文档当"地图"而非"百科全书"。Agent 启动时只读顶层目录，按需加载深层文档。直接把所有规范塞进一个巨大的系统提示词，会导致"一切都重要等于一切都不重要"。

2. 机械化的架构约束

将"品味"和"架构规范"编码为自动化规则。当 Linter 或 CI 报错时，在错误信息中注入修复指令，让 Agent 能自我修正。

3. 机器可读的可观测性

让 Agent 接入真实运行时环境——独立沙箱、日志查询、浏览器自动化。Agent 不能只"脑补"结果，必须看到实际执行的输出。

4. 自愈与闭环控制

强制的验证闭环：Agent 不跑测试不准声称完成。死循环检测：同一文件被编辑超过 N 次时强制打断。智能体互审：开发 Agent 写代码，审查 Agent 做 review。

5. 防熵增与垃圾回收

AI 生成代码的速度极快，系统会迅速累积技术债务。需要文档园丁 Agent（自动更新文档）和技术债清理 Agent（定期重构）。

Harness Engineer 的职责

Harness Engineer 不训模型、不写 prompt 模板。他们的工作是：

• 实现工具：定义 Agent 能做什么
• 策展知识：决定 Agent 能看到什么
• 管理上下文：控制信息的注入时机和方式
• 控制权限：划定 Agent 的安全边界
• 收集训练数据：Agent 的行为日志反哺模型训练

核心哲学（Manus 视角）

季逸超（Peak）在张小珺的采访中给出了一个精炼的总结：

"做对一千件小事，比做对三件大事更重要。"

这与 Rich Sutton 的《The Bitter Lesson》一脉相承：那些依赖人类精心设计的规则和知识的方法，最终都会被更简单粗暴、能更好利用算力进行通用学习的方法打败。

翻译到 Agent 工程中：不是提前设计三条聪明的规则（Workflow），而是让系统在面对一千种不同情况时，每次都能做出还算合理的判断（Agent）。单看每一次判断，可能都不完美；但整体叠加起来，能处理的问题范围就远超任何规则系统。

---

1.4 智能 Agent vs 规则 Agent 的抉择

两条路线

现有的 Agent 产品大致分成两类：

维度	规则主导（Rule-driven Agent / Workflow Agent）	智能主导（Smart Agent / 纯血 Agent）
控制流	开发者预设分支和流程	模型每一步自行判断
优势	可预测、可复现、成本低	灵活、处理意外情况、天花板高
劣势	天花板等于设计者想象力	不够稳定、偶尔犯蠢
隐含假设	模型能力是辅助，规则是核心	模型能力会持续提升，规则应最小化

Manus 的选择：信任模型进步

Manus 选择了"智能主导"路线。Peak 在访谈中给出了清晰的理由：

1. 规则主导的天花板问题无解——你永远没办法提前预见用户会遇到的所有情况。
2. 稳定性问题可以解决——通过更好的 Harness（反馈机制、视觉验证、错误恢复）让模型自我纠正。
3. 押注模型进步是低风险策略——"谁进步了，他们就受益。"

一个具体例子：传统做法处理数据可视化中的乱码/排版问题，是为各种语言/字体写大量规则和提示；Manus 的做法是给 Agent 一个"看图能力"，让它自己看到乱码后修复。前者解决已知问题，后者的泛化能力覆盖未知问题。

通用 Agent vs 垂直 Agent

Peak 在访谈中提出了一个反直觉的观点：底层供给（通用模型 + 图灵完备环境）本来就是通用的，做垂直反而是在上层加约束。

三个层面的理由：

技术供给层：Manus = 通用模型 + 计算机（虚拟机/图灵完备环境）。底层供给（base supply）已经通用化，做垂直 Agent 等于人为设限。

产品发现层：先给通用架构，让用户按想象力使用。团队通过脱敏统计捕获头部场景，再做最后一公里优化。这是"达尔文方式"——让需求自然演化，而非预设。

增长与心智层：垂直场景（如旅行规划）对普通人低频，一年两三次。通用 Agent 覆盖更多任务类型，使用频次更高，更容易成为"高价值工作流的一部分"。

Agent 的三个基本面

Peak 把 Agent 抽象成三个要素：

1. Model     — 不自训，选最优的用
2. Environment / Sandbox — 关键边界条件
3. User interaction — 减少 prompt 负担，增加主动性

Model：Manus 不自己训模型。他们把精力花在"怎么更好地使用模型"上。所有外部的模型创新都是养料和供给——Anthropic 的 Claude 变强了，他们直接受益；OpenAI 的 reasoning 提升了，他们切换过去。这是一个风险极低的策略。

Environment / Sandbox：每个会话背后是独立沙盒、一次性虚拟机。这是 Agent 最关键的边界条件。Manus 选择 Firecracker 的全虚拟化而非 Docker，因为容器绑定 Linux 生态，很多专业软件在 Windows。

User interaction：当前最大的用户瓶颈是入口仍是 prompt。未来方向是让 Agent 主动从上下文（Notion、会议记录、业务系统）中获取信息，提前完成工作，只向用户请求确认。

---

1.5 主流 Agent 项目的定位图谱

要理解 Agent 的工程全貌，需要从三个维度审视当前主流项目：教学实现、生产系统、理论研究。

教学实现：从最小原型到完整系统

理解 Agent 最好的方式是亲手构建一个。教学类项目按复杂度递增可分为三个层次：

graph LR
    L1["入门：Python 最小实现<br/>一个循环构建 Agent"]
    L2["进阶：TypeScript 架构解析<br/>生产级 Agent 各组件"]
    L3["验证：Rust 极简复刻<br/>千行代码复现核心"]
    L1 --> L2 --> L3

入门级：用 Python 从零构建 Agent。第一步用 30 行代码实现 Agent Loop，第二步添加工具分发，后续逐步叠加子 Agent、技能加载、上下文压缩等机制。核心哲学是"循环不变，一切叠加"。

进阶级：以生产级开源 Agent 为案例，系统剖析完整架构。从 LLM 接口到 Tools 注册、从 Memory 管理到 Planning 策略、从 Execution Loop 到错误恢复，每个组件的职责和交互方式都需要逐一理解。

验证级：用 Rust 等系统语言实现极简 Agent 复刻，约一千行核心代码。目的是验证"Agent 的本质结构真的很简单"这一论点——去掉所有生产级的复杂性后，核心循环依然清晰可辨。

生产系统：真实产品的工程实践

主流 Agent 产品在工程实践上各有侧重：

graph LR
    T1["Codex CLI (OpenAI)<br/>沙箱·安全·规模化"]
    T2["Claude Code (Anthropic)<br/>工具·上下文·权限"]
    T3["开源 Agent 框架<br/>多端·多模型·插件·评估"]
    T1 --- T2 --- T3

沙箱与安全：以 Codex CLI 为代表，重点解决的问题包括 Linux 沙箱隔离、网络代理与访问控制、文件搜索优化、apply-patch 式的代码编辑策略。Rust 内核保证了性能和安全边界。

工具与上下文：以 Claude Code 为代表，核心能力在于丰富的工具集（文件读写、Shell 执行、浏览器操控）、分层权限模型、以及 CLAUDE.md 等结构化知识注入机制。

开源框架：多端 AI Coding Agent（如 OpenCode）采用客户端/服务器分离架构，支持多模型切换（Claude/GPT/Gemini/本地模型），核心流程从入口到服务、到消息处理、到 LLM 调用和工具注册层层递进。深度 Agent 框架（如 LangChain 生态的 DeepAgents）则侧重评估框架、Agent 编排协议、远程沙箱对接和 Deep Research 等高级能力。

理论研究：超越代码的思考框架

Agent 领域的理论研究覆盖多个维度：Harness Engineering 综述、Manus 团队的实战经验、Agentic RL（将 RL 思想引入 LLM Agent 训练）、Context Engineering 最佳实践、RAG 与长期 Memory 设计等。这些理论材料提供了超越具体实现的认知框架，帮助理解"为什么这样设计"而不仅仅是"怎么实现"。

定位图

graph TD
    subgraph 教学线
        L1["入门<br/>Python 最小实现"]
        L2["进阶<br/>TypeScript 架构解析"]
        L3["验证<br/>Rust 极简复刻"]
    end
    subgraph 生产线
        P1["沙箱·安全<br/>Codex CLI"]
        P2["工具·上下文<br/>Claude Code"]
        P3["多端·评估<br/>开源框架"]
    end
    subgraph 理论线
        T1["Agent 理论研究<br/>Harness · Manus · RL"]
    end

    L1 -->|"循环不变"| L2
    L2 -->|"极简复刻"| L3
    T1 -->|"理论支撑"| P1
    T1 -->|"理论支撑"| P2
    T1 -->|"理论支撑"| P3
    L1 -.->|"概念对照"| P1
    L2 -.->|"架构对照"| P3

阅读建议

• 如果你想快速理解 Agent 是什么：从 Python 最小实现开始，30 行代码建立直觉。
• 如果你想看生产级实现：Codex CLI 的 Rust 内核或开源 TypeScript Agent 架构二选一深入。
• 如果你关心理论基础：Harness Engineering 综述和 Manus 团队的实战经验是必读材料。
• 如果你要做自己的 Agent：先通过教学项目建立架构认知，再根据你的语言偏好选择 Rust 或 TypeScript 的生产级实现作为参考。