三大工程维度
通过三个正交维度构建智能体稳定性框架，综是综合 Martin Fowler 系（Böckeler）、Anthropic Rajasekaran、Phil Schmid 三家博客里反复出现的工程主题。
输入端 ✖️ 控制流 ✖️ 状态流
graph LR
subgraph 输入端
A[Context Engineering
上下文工程]
A_desc["核心：管控Agent「看见」的信息
案例：RAG提示词｜会话压缩｜进度持久化
本质：筛选、整理输入信息"]
end
subgraph 控制流
B[Architectural Constraints
架构约束]
B_desc["核心：管控Agent「能做」的动作
案例：Hook钩子｜权限闸门｜子Agent隔离
本质：划定行为红线，限制操作边界"]
end
subgraph 状态流
C[Garbage Collection
上下文GC回收]
C_desc["核心：管控Agent「持续运行」时长
案例：Token预算｜上下文压缩｜过期清理
本质：动态收敛，策略性遗忘"]
end
A --- B --- C
| 模块 | 核心定位 | 核心问题 | Claude Code 实践案例 | 本质 | 代表机制 |
|---|---|---|---|---|---|
| Context Engineering上下文工程【输入端】 | 管控 Agent 的信息输入 | 怎么在第一时间把对的资料喂给它 ✅ Agent 能看见什么？ |
1. CLAUDE.md：项目目录级 RAG 系统提示词 2. session compaction：长会话自动压缩上下文 3. progress 文件：进度落盘，跨 session 续传 |
整理 Agent 看见的信息 | Context Management、Feature List、Progress Tracking、Subagents |
| Architectural Constraints架构约束【控制流】 | 约束 Agent 行为边界 | 它发疯的时候，怎么硬生生按住它 ✅ Agent 能做什么？ |
1. 27 种 hook：工具调用前后插入约束 2. Permission Gate：危险操作人工确认 3. Task tool /subagent：分治隔离，主上下文不污染 |
设红线、拉电闸，约束 Agent 可执行范围 | Agent Loop、Tool Use、Verification Loop、Generator-Evaluator |
| Garbage Collection上下文回收【状态流】 | 动态管理上下文生命周期 | 内存快被撑爆时，怎么有策略地遗忘 ✅ Agent 能跑多久？ |
1. token budget：防爆预算，超限强制收敛 2. session compaction：回收过期上下文 3. compaction → reset：Anthropic 2025→2026 路线 |
容错与动态收敛，策略性遗忘 | Context Management (辅)、Feature List (辅)、Subagents (辅)、Token Budget |
三支柱核心问题与判断规则
| 维度 | 核心问题 | 判断规则 |
|---|---|---|
| Context Engineering | Agent 能看见什么信息？看见的信息是否准确精简？ | 如果一个机制在”整理 agent 接下来输入的信息”，它属于这一柱 |
| Architectural Constraints | Agent 能做什么、不能做什么？动作空间在哪里有边界？ | 如果一个机制在”约束 agent 的能力或交互边界”，它属于这一柱 |
| Garbage Collection | Agent 能跑多久？成本和资源怎么回收？ | 如果一个机制在”清理过期状态 / 限制成本 / 回收资源”，它属于这一柱 |
来源说明：三维度不是单一作者的原创定义，是本课程综合 Martin Fowler 系博客（Böckeler 2026-04-02）、Anthropic Rajasekaran（2026-03-24）、Phil Schmid（2026-01-05）多来源抽象的工程维度框架。
我们用 Claude Code 完整走一次三维度归类，从定义变成可验证的判断：
Context Engineering (输入端：怎么在第一时间把对的资料喂给它)：Claude Code 读取你项目目录里的 CLAUDE.md（相当于 RAG 系统 prompt）、在长会话时触发 session 压缩（compaction）、把进度写进 progress 文件——这三项都在”整理 agent 看见的信息”。
Architectural Constraints (控制流：它发疯的时候，你怎么硬生生把它按住)：Claude Code 提供 27 种 hook 让你约束工具行为、内置 Permission Gate 控制危险操作、通过 Task tool（subagent 机制）做分治隔离——这三项都在”约束 agent 能做什么”（设红线、拉电闸）。
Garbage Collection (状态流：内存快被撑爆时，怎么有策略地遗忘)：Claude Code 有 token budget 防爆预算、做 session compaction 回收过期上下文；Anthropic 2025→2026 的工程路线注释也在从 compaction 逐步转向 reset——这条支柱核心是容错与动态收敛。
八大机制与三维度的对照表
八大机制 × 三维度归属
| 机制 | Context Engineering | Architectural Constraints | Garbage Collection | 归属判断说明 |
|---|---|---|---|---|
| 1 Agent Loop 四相循环 | 辅 | 主 | - | 循环每轮都要整理 context；四相结构本身是架构约束 |
| 2 Tool Use 工具编排 | - | 主 | - | 工具 schema 本身就是一个动作空间的约束 |
| 3 Progress Tracking | 主 | 辅 | - | 跨 session 的状态持久化属于 context 延展 |
| 4 Context Management | 主 | - | 辅 | 本柱的核心；compaction 也有 GC 属性 |
| 5 Feature List | 主 | 辅 | 辅 | JSON 清单是 context 的规划层 |
| 6 Verification Loop | - | 主 | - | 事件驱动的错误显性化属于架构约束 |
| 7 Subagents | 主 | 辅 | 辅 | 分治隔离是架构性的边界划分 |
| 8 Generator-Evaluator | - | 主 | - | 三角色分离是架构约束的典型实现 |
Harness产品
主流Harness产品清单
| # | 产品 | 开发方 | 1 句定位 |
|---|---|---|---|
| 1 | Claude Code | Anthropic | CLI-first 驾驭工程参考实现，Anthropic 官方博文对其机制的文档化程度较为详尽（含 MCP / Subagent / Hook / Skill 等子系统） |
| 2 | Codex CLI | OpenAI | CLI-first，OpenAI 官方 harness 参考 |
| 3 | Cursor | Anysphere | IDE-native harness，VS Code 深度集成 |
| 4 | Windsurf | Codeium | IDE-native，IDE 端体验对标 Cursor |
| 5 | Cline | VS Code 社区 | IDE-native 开源插件，autonomous agent 特色 |
| 6 | Aider | 开源社区 | CLI-first 开源，git commit 深度集成 |
| 7 | Amp | Sourcegraph（2026-02-19 转 CLI-only） | CLI-first，代码搜索 + agent 结合 |
| 8 | Roo Code | 开源社区 | IDE-native VS Code 扩展，Cline 分支演化 |
| 9 | DeepAgents | LangChain | SDK-harness，基于 LangGraph 的 harness 组件库 |
| 10 | Devin | Cognition | Cloud-sandbox，完全托管的 autonomous agent |
| 11 | JetBrains Junie | JetBrains | IDE-native，JetBrains 系 IDE 集成 |
Harness 的四种形态
mindmap
root((Harness的四种形态))
CLI-first 命令行系【终端】
理念：长任务后台运行，异步等待结果
擅长：长任务、脚本流水线、CI/CD集成
踩坑：错误易吞没、中间状态不可见
场景：批量改造、autorun迁移、夜跑任务
代表：Claude Code, Codex CLI, Amp, Aider
IDE-native 客户端系【编辑器】
理念：跟随光标，边写边改
擅长：行内补全、diff可视化、即时变更确认
踩坑：上下文碎片化，大范围重构受限
场景：日常编码、结对编程、轻量重构
代表：Cursor, Windsurf, GitHub Copilot Chat
Cloud-Sandbox 云端沙盒系【云端】
理念：云上隔离环境，开发者持有控制权
擅长：托管环境、安全隔离、异步长任务
踩坑：冷启动慢、本地文件上云合规复杂
场景：企业合规、远程Agent、跨设备协作
代表：Devin, Replit Agent, E2B
SDK-Harness 库系【底层库】
理念：提供积木，自主搭建产品
擅长：深度定制、内置自有产品、研究原型
踩坑：需自研观测能力，学习曲线陡峭
场景：自研Agent产品、科研实验
代表：DeepAgents, LangGraph, AutoGen
| 分类 | 定位与核心理念 | 擅长能力 | 典型痛点 | 适用场景 | 代表产品 |
|---|---|---|---|---|---|
| CLI-first 命令行系【终端】 | 长任务放进终端，后台执行，离线等待结果 | 长任务自主运行、脚本流水线、CI/CD 集成 | 无人值守错误容易吞没；任务中间状态不可视 | 批量代码改造、代码迁移、夜间自动任务 | Claude Code、Codex CLI、Amp、Aider |
| IDE-native 客户端系【编辑器】 | 边写边改，跟随光标，紧贴开发流程 | 行内代码补全、diff 可视化、即时接受 / 拒绝改动 | 高频交互造成上下文碎片化；大范围重构能力受限 | 日常编码、结对编程、轻量代码重构 | Cursor、Windsurf、GitHub Copilot Chat |
| Cloud-Sandbox 云端沙盒系【云端】 | 提供云上隔离环境，开发者掌控权限 | 全托管运行环境、安全隔离、异步长任务 | 冷启动速度慢；本地文件上传同步合规成本高 | 企业合规开发、远程 Agent、跨设备协作 | Devin、Replit Agent、E2B |
| SDK-Harness 库系【开发库】 | 不提供成品工具，提供底层积木自由搭建 | 深度定制、嵌入自有系统、科研原型搭建 | 需要自研观测体系（observability）；上手门槛高 | 自研 Agent 平台、学术研究、定制化产品 | DeepAgents、LangGraph、AutoGen |
四系家族特征对比
| 家族 | 主要特征 | 典型代表 | 适用场景 | 局限性 |
|---|---|---|---|---|
| CLI-first | 命令行为主入口，跑在本地 terminal | Claude Code / Codex CLI / Aider | 后端开发、系统工程、对 CLI 有强偏好的开发者 | 需要命令行习惯，无 GUI，非程序员门槛高 |
| IDE-native | IDE 内置集成，UI 优先 | Cursor / Windsurf / Cline / Junie | 前端开发、对 IDE 生态有依赖的开发者 | 重依赖特定 IDE 生态，跨 IDE 迁移成本高 |
| Cloud-sandbox | 云端完全托管，无需本地环境 | Devin | 团队协作、需要远程长任务托管 | 成本较高、数据隐私顾虑、本地文件系统访问受限 |
| SDK-harness | 提供 SDK 自建 harness | DeepAgents (LangChain) | 定制化场景、需要把 harness 嵌入自家产品 | 集成复杂度高，需要自行维护 harness 运行时 |
官方建议
【建议一】 harness 会过时
“A harness encodes assumptions that go stale. What works for Claude 3.5 may not work for Claude 4.5.”——Anthropic 官方博文（2025-11-26 Effective Harnesses for Long-Running Agents，Justin Young）
翻译：harness 固化了一组关于模型的假设，这些假设会过期。对 Claude 3.5 有效的 harness，换成 Claude 4.5 可能就失效了。
对我们的含义：不要把 harness 当成一次性架构写死，要像管理软件一样持续迭代。
排查方法：判断你的 harness 是否开始过时的信号——同样任务的成功率下降 5pp 以上、需要频繁手动干预、新模型版本上线后 benchmark 反而退步。出现任一条就该考虑裁剪 harness 而非继续加码。
具体信号/行动：
怎么判断、怎么做
信号：同类任务成功率连续下降 5pp 以上
信号：新模型上线后旧 harness benchmark 反而退步
行动：每次模型升级后跑一次 benchmark 对比
术语解读
- pp：percentage point，百分点。下降 5pp 即指标绝对值降低 5 个百分点。
- harness：AI 领域常用，指自动化评测调度框架，用于批量执行测试用例。
- benchmark：基准测试，固定测试数据集，用来量化模型能力，做版本横向对比。
业务含义说明
这是大模型迭代过程中的模型退化（regression）监控策略：
- 两类预警信号，用来及时发现新版本模型能力变差；
- 标准处置动作：模型每次版本升级，必须完整执行基准评测，和旧版本指标对比，提前识别性能滑坡。
【建议二】 Build to Delete（建造以便删除）
“The best harness is the one you’re most willing to throw away and rewrite. The dataset of failures from your current harness is more valuable than the harness itself.”——Phil Schmid 博文 2026-01-05（Bitter Lesson 三原则之一）
翻译：最好的 harness 是最愿意扔掉重写的那个。当前 harness 的失败样本比 harness 本身更有价值。
对我们的含义：不要给 harness 加舍不得删的复杂度。Manus 团队 6 个月重构 5 次的故事，本质就是这句话的实战演绎。
后果：舍不得删 harness 的后果是——随模型能力提升，过时的刚性控制流反而降低成功率；Manus 五次重构的每一次，都是因为上一版”舍不得删的设计”成了下一版的瓶颈。
具体信号/行动：
怎么判断、怎么做
› 信号：改一个 bug 牵动 5+ 处刚性流程 —— 刚性过强该重写
› 参照：Manus 团队 6 个月重构 5 次的节奏
› 行动：failure log 当一等公民留存，harness 可以扔，数据不能扔
术语与理念解读
- 刚性流程 代码耦合严重，一处逻辑改动会连锁影响多处模块，修改成本极高、极易引发次生 bug，是系统需要重构的典型信号。
- failure log（失败日志） 故障、用例失败的原始日志，是定位问题、沉淀测试案例的核心资产，需要长期保存。
- harness 自动化评测 / 执行框架，属于上层工程载体；框架代码可以迭代、废弃。
- 核心思想 原始业务数据、失败样本具备长期价值；承载测试的工程框架可以随时重构迭代。
Manus 是通用智能体团队，高频持续重构是其技术迭代策略，持续拆解消除系统耦合。
【建议三】 三大开放争议还没定论
驾驭工程作为新学科，有三个核心设计选择社群仍在争论，目前没有统一答案：
- 多 Agent（Subagents 分治）vs 单 Loop（Feature List 拆分）：Anthropic 和 OpenAI 偏前者，LangChain 部分产品偏后者。推理层：多 Agent 隔离性更好但协调开销更大（主 agent 要处理子 agent 的 return 协议、失败重试策略）；单 Loop 简单可控但 context 膨胀压力全在一个 loop 里——Anthropic 偏多 Agent 因为其 Task tool 天然支持，LangChain 的 Feature List 偏单 Loop 因为有 LangGraph checkpoint 做状态保障。
- Compaction（压缩旧 context）vs Reset（重置 context 重来）：Anthropic 2025 年偏 compaction，2026 年 3 月前后开始偏 reset。推理层：compaction 保留历史上下文但引入摘要噪声（摘要本身可能丢失关键信息，且给 LLM 增加”去噪”负担）；reset 干净但丢失跨 session 推理链——所以 reset 方案强依赖 Progress Tracking 和 Feature List 做外置记忆补救。
- CLI-first vs IDE-native：Claude Code / Codex CLI 路线 vs Cursor / Windsurf 路线，两种哲学尚未分出胜负。推理层：CLI-first 擅长”长任务自主运行 + 脚本化可编排”，IDE-native 擅长”行内交互式修改 + 视觉反馈”——两者面向不同的工作流场景。
对我们的含义：如果有人告诉你”正确答案就是 X”，保持警惕——这门学科还在演化中。
如果有人告诉你 “正确答案就是 X”，保持警惕 —— 驾驭工程还在演化中！
具体信号/行动：
怎么判断、怎么做
› 现象：Anthropic 倾向单 Loop，OpenAI / 多 Agent 派活跃
› 现象：Compaction → Reset 2026 才见雏形路线
› 行动：不盲从单一观点，跟踪 3-6 个月社群共识变化
术语简要解读
单 Loop / 多 Agent 智能体两条主流技术路线：
Anthropic 偏向单智能体循环（Single Loop）：依靠单个模型持续迭代思考；
OpenAI 侧更多探索多 Agent：多个智能体分工协作、相互博弈。
Compaction → Reset 智能体记忆管理方案：Compaction（记忆压缩），Reset（状态重置），属于长时序智能体核心技术方案，文档观点认为该技术路线预计 2026 年才会形成成熟方案。
核心思想 当前 Agent 工程领域没有绝对最优范式，各家路线分歧明显，不要迷信唯一标准答案，需要长期持续跟踪行业技术演进。