[Harness] Arch Think, Act and Evolve
这条主线可以叫：从 LLM 到 Agent System 的架构演进
更完整一点：
- LLM
- Prompt Engineering：让模型回答得更好；
- Harness Engineering：让模型能用工具、记忆、权限；
- Loop Engineering：让模型能持续执行任务；
- Graph Engineering：让多个任务流程可控组合；
- Memory / Skill Engineering：把经验变成可复用能力；
- Self-improving Agent System：让 Agent 逐步进化。
Harness Engineering
一个裸模型外面，需要加什么东西，才能变成真正可用的 Agent？
可以把裸 LLM 理解成一个“大脑”。
它会思考、会生成文本，但它本身没有手、没有眼睛、没有长期记忆，也不能直接操作外部系统。
Harness Engineering 做的事情，就是给这个“大脑”装上一套外骨骼，让它真正具备执行任务的能力。它通常包括：
| 组件 | 形象理解 | 作用 |
|---|---|---|
| tools | Agent 的“手” | 让 Agent 能调用 API、查数据库、发请求、操作外部系统 |
| memory | Agent 的“长期笔记本” | 让 Agent 记住用户、项目背景、历史经验和长期偏好 |
| skills | Agent 的“熟练工序” | 把反复做过的任务沉淀成可复用能力，下次可以更稳定地执行 |
| context management | Agent 的“工作台整理能力” | 从大量信息里挑出当前任务最相关的内容，避免上下文混乱 |
| permissions | Agent 的“门禁系统” | 控制 Agent 能访问什么、能操作什么、不能越权做什么 |
| human approval | Agent 的“人工签字流程” | 在高风险动作前让人确认，例如发邮件、改配置、删数据 |
| logging | Agent 的“行车记录仪” | 记录每一步做了什么，方便调试、审计和追踪问题 |
| evaluation | Agent 的“质检员” | 检查结果是否正确、完整、安全，避免错误输出直接交付 |
| retrieval | Agent 的“资料检索员” | 从文档、知识库、历史记录中找到相关材料，补充模型不知道的内容 |
| file system | Agent 的“文件柜” | 让 Agent 能读取、写入、整理和生成文件 |
| browser | Agent 的“网页眼睛和手” | 让 Agent 能打开网页、阅读页面、点击按钮、填写表单 |
| code execution | Agent 的“实验室/计算器” | 让 Agent 能运行代码、处理数据、验证假设、生成图表或文件 |
Link：Harness Engineering 深度解析：AI Agent 时代的工程范式革命
2026 年 2 月，"Harness Engineering"这个词突然在 AI 工程圈子里火了起来。Mitchell Hashimoto 在博客里提了这个说法，OpenAI 紧接着发了百万行代码的实验报告，Martin Fowler 也跟进写了深度分析——几周之内，这个术语就成了讨论 AI Agent 开发绕不开的话题。
- Context Engineering 管的是"给 Agent 看什么"，例如：记忆管理。
- Harness Engineering 管的是"系统怎么防崩、怎么量化、怎么修"。
== Why Coding Agent First? ==
例如 Deep Research Agent：
[1] Codng Agent 是一个成功的案例，也是一套框架的类比示范
| Coding Agent | Deep Research Agent |
|---|---|
| 代码仓库 | 资料库与互联网 |
| compiler | 格式与逻辑检查器 |
| unit tests | factuality evaluator |
| Git history | research trace |
| code review | source/citation review |
| architecture rules | research methodology |
| CI | 自动质量门禁 |
| PR | 最终研究报告 |
| failing test | 证据不足或来源冲突 |
[2] 以下是类比的思考过程
而「做研究」以前没有这套裁判——AI 写完一篇报告，对不对全靠人肉去看。所以这张表干的事就是：把程序员那套裁判，一个一个照搬到研究上。逐行翻译成人话：
- 代码仓库 → 资料库与互联网：干活的原材料从哪儿拿。程序员从代码库拿，研究员从资料和网上拿。
- 编译器 → 格式与逻辑检查器：编译器管的是「低级错误」——语法写错就不让你跑。对应到研究，就是「你这段前后自相矛盾 / 格式不对」，先拦一道。这层不管你说得对不对，只管明显不通。
- 单元测试 → 事实核查器：单元测试是「给你一道题和标准答案，看你算得对不对」。研究里就是「你说 GDP 涨了 5%，我去查查真是 5% 吗」。这层管内容真假。
- Git 历史 → 研究轨迹：Git 记录每行代码谁改的、为什么改，出事能倒查。研究轨迹就是记录「这个结论我是一步步怎么查出来的」，别人能顺着走一遍。
- 代码评审 → 来源/引用审查：同事看你代码写得糙不糙；对应的是别人检查你引的资料靠不靠谱、有没有瞎引、引偏了。
- 架构规范 → 研究方法论：写代码有「该怎么分层、怎么组织」的规矩；做研究有「该怎么取样、怎么对比、怎么下结论」的规矩。都是「怎么干才算专业」。
- CI → 自动质量门禁：CI 是那个「你一提交，机器自动把上面所有检查跑一遍，没过就打回」的机器人。研究版就是自动跑一遍格式+事实+引用检查，不合格不让发。
- PR → 最终研究报告：程序员干完活最后交出去等审批的那个「成品包」。研究员交的就是报告。
- 测试挂了 → 证据不足或来源冲突：代码里「测试红了」是个明确信号：这儿有问题，回去改。研究里的红灯就是「这条我查不到证据」或者「两个来源说得不一样」——这就是让 AI 回头继续查的触发器。
[3] 最后则是定型
所以 Deep Research Agent 也需要自己的 Harness：
- 搜索工具
- 网页读取工具
- 来源质量判断
- 引用追踪
- 去重机制
- 事实验证
- 冲突证据识别
- context compression
- research plan
- evaluator
- retry loop
- 最终报告结构
所以，Coding Agent 是第一个把这些组成部分大规模组合起来，并通过真实生产任务证明其重要性的领域。因此，Harness Engineering 这个统一术语首先在 Coding Agent 社区中成熟和流行，之后才逐渐被推广到 research agent、computer-use agent、customer-service agent 等更广泛的智能体系统。
== 经验性总结收敛 ==
另外，得到一些实践经验
OpenAI 团队说得很直接：
真正卡你的不是 Agent 写代码的能力，而是围绕它的结构、工具和反馈机制跟不上. 五个独立团队得出了相同结论：基础设施才是瓶颈，而非智能水平。
Anthropic 在做长时间运行 Agent 的过程中，总结了 Agent 常见的翻车姿势：
失败模式 2：过早宣布胜利。
失败模式 3：过早标记功能完成。
败模式 4：环境启动困难。
Dex Horthy 有个很实用的经验观察：
上下文填得越满，LLM输出质量越差。以 168K token 的上下文窗口为例，大约用到 40% 就开始走下坡路了：
Smart Zone（前约 40%）：聚焦、准确的推理。Agent 拥有相关、精炼的信息。
Dumb Zone（超过约 40%）：幻觉、循环、格式错误的工具调用、低质量代码。更多 token 反而损害性能。
也就是说，给 Agent 塞一堆 MCP 工具、冗长文档和累积的对话历史，不会让它更聪明——反而会让它变笨。
Jeff: 测试的标准很重要，需求细节很重要，条理顺序很重要。但写好这些貌似很费神费力，所以，第一步可以让Agent先写文档，而非代码。
综合 OpenAI、Anthropic、Carlini（C 编译器项目）、Huntley、Horthy 等五个独立团队的实践，四种模式反复出现并形成收敛。这就是 Harness Engineering 的四大支柱。
也就是说，先有多个独立案例，后来有人把其中反复出现的做法进行横向比较，再归纳成四类。
支柱一：上下文架构（Context Architecture）
支柱二：Agent 专业化（Agent Specialization）
支柱三：持久化记忆（Persistent Memory）
支柱四：结构化执行（Structured Execution）
For more details, please check: [Harness] Four pillars define harness engineering - Alex Lavaee
原文：https://alexlavaee.me/blog/harness-engineering-why-coding-agents-need-infrastructure/ # 年纪轻轻，影响力不小
== 是否存在 “通用 Harness”？==
存在，但只能通用到某一层。
例如企业可能建设一个内部 Agent Platform，统一提供：
- 模型网关
- authentication
- tools registry
- logging
- evaluation
- memory
- deployment
- observability
- permission control
然后不同部门在上面建设自己的业务 Harness。
Harness 通常有三层
第一层：通用基础 Harness
第二层：领域 Harness
第三层：具体公司的业务 Harness
2026.2月左右，通用基础的概念形成过程
(1) Mitchell Hashimoto：提出核心原则
Agent 每犯一次错，都应转化成 Harness 的永久改进。
↓
(2) OpenAI：展示产品级实践
三名工程师通过建设完整 Harness，让 Codex 可以持续开发真实的大型产品。
↓
(3) Ethan Mollick：建立大众化概念模型
AI 产品不能只看 Model，还要同时看 App 和 Harness。
↓
(4) Birgitta Böckeler / Martin Fowler 网站：进行软件工程分类
Harness 可以从 Context、Architecture Constraints 和 Garbage Collection 等角度系统分析。
== Hermes的角色呢？ ==
Hermes的核心价值是提供第一层；
它同时提供Skills、MCP、Context和Subagent等扩展机制，使开发者能够在其上建设第二层，但具体的领域Harness通常需要社区或企业自己开发。
第三层则几乎一定需要具体公司完成。
如果你已经确定要做成公司的长期系统，那么直接用 LangGraph可能更省事，避免先在Hermes中深度开发，后来又重写一次。
Hermes更适合你还不确定以下问题的时候：(R&D)
- 这个想法到底有没有实际使用价值；
- 用户会怎样与Agent交互；
- 需要哪些Skills和工具；
- 是否真的需要Multi-Agent；
- 自动化应该做到什么程度。
第一阶段：Hermes负责调用这些能力
第二阶段：LangGraph负责调用同一批能力
Sean‘s AI Stories
Sean‘s AI Stories 过去一年的视频都有必要过一遍！！
You Can Learn AI Agent System Design In 19 Min | RAG, Vector Database, Evals, Function Calling # 内容类似LangGraph的课程体现的内容，理解难度低。
You Can Learn RAG AI Agent Design & Launch In 35 Min | Supabase Vector Database, Google Cloud GCP # RAG部分，但一笔带过，有必要“再学习”。
- Please Goto: [agent] RAG # 顺便瞧瞧 Paulo 的水平
- Please Goto: [agent] Deep Research # Web Agent 的高阶版本？
You Can Learn AI Agent Harness & Loop Engineering In 19 Min | LLM Ops, Eval, Tracing, RAG
- Please Goto: [Harness] Loop Engineering
Harness Engineering（驾驭工程）
----> 在 2026年初 提出，因为代理开始在真实生产环境中执行更长、更自主的多步骤工作。
Loop Engineering（循环工程）
----> 由Google Chrome工程主管Addy Osmani在 2026年6月7日 正式创造这个术语，这是继Harness Engineering之后提出的。
Continue ...
浙公网安备 33010602011771号