一个好演员，配一个烂剧组，拍出来的还是烂片。
AI Agent 也一样。你换了 Claude Opus 5，换了 GPT-5.6，结果它还是失忆、死循环、工具调不对——问题不在演员，在剧组。
这个"剧组"现在有了正式名字：Harness。提示词、工具编排、记忆管理、上下文截断、沙箱隔离、评估反馈……模型之外的一切，都是 Harness。
2026 年，Harness Engineering 突然成了 AI 工程圈最热的话题。Addy Osmani 写了长文，Lilian Weng 发了博客，Viv Trivedy 造了词，Anthropic 公开了自己的 Harness 设计——所有人都在说同一件事：Agent = Model + Harness，你一直在优化左边，但杠杆在右边。
小米的 Darwin Agent 团队把这句话当真了。他们造了一个叫 HarnessX 的开源项目，把 Harness 从"写死在代码里的配置"变成了可组合、可自适应、可进化的一等对象。
一个公式，拆开看
HarnessX 的核心抽象只有一行：
agent = model.agentic(harness)
左边是模型（ModelConfig），管路由、fallback、角色分配。右边是 Harness（HarnessConfig），管全部行为管线——工具、记忆、处理器、追踪、沙箱。
以前换模型容易，换行为难。从编码 Agent 切到研究 Agent，你得重写整个 Agent。HarnessX 把行为抽出来，像换插件一样换 Harness。
9 维行为管线
HarnessX 把 Agent 行为拆成 9 个正交维度，对应三个支柱：
| 支柱 | 维度 | 管什么 |
|---|---|---|
| 🧩 组合 | Model / Context / Memory / Tools / Sandbox | 模型选择、上下文组装、记忆管理、工具生态、执行环境 |
| ⚙️ 适配 | Evaluate / Control | 评估奖励、安全控制 |
| 🚀 进化 | Observe / Train | 可观测性、训练桥接 |
每个维度里的行为都是一个 Processor，用 | 运算符组合：
config = (make_coding(working_dir=".") | make_reliability()).build()
冲突检测是强制的——如果两个 Bundle 争同一个单例槽位，直接抛 HarnessConflictError，不会静默覆盖。
Control 维度尤其值得说：13 个处理器，包括循环检测、成本守卫、上下文压缩、谄媚检查（sycophancy check）。这些是 Agent 跑长任务时不崩的关键，但大多数框架要么没有，要么你得自己拼。
AEGIS：让 Harness 自己改自己
组合只是第一步。HarnessX 的杀手锏是 AEGIS——一个四阶段自适应引擎：
- Digester：压缩执行轨迹，提取失败模式
- Planner：根据失败模式规划适配策略
- Evolver：生成 Harness 变体候选
- Critic：评估变体，只有确认有改进才放行
这不是简单的"换个 prompt 重试"。AEGIS 把 Harness 适配变成了一个可追溯、可审计的优化过程——每次改动都有 Change Manifest，记录改了什么、为什么改、效果如何。
论文还指出了三种 RL 病理在 Harness 适配中的映射：
- Reward hacking：Harness 学会了"作弊"通过评估，但实际能力没提升
- Catastrophic forgetting：新轮次的适配覆盖了之前的有效配置
- Under-exploration：Harness 过早收敛到局部最优
AEGIS 的 Critic 阶段就是专门对付这些问题的——它不是无脑接受改进，而是主动检测退化。
数据说话：弱模型受益最大
5 个基准测试，平均 +14.5%，最高 +44.0%（ALFWorld）：
| 基准 | 提升幅度 | 特点 |
|---|---|---|
| ALFWorld | +44.0% | 文本交互，基线最低，提升最大 |
| GAIA | +18.7% | 通用推理 |
| WebShop | +12.3% | 网页购物 |
| τ³-Bench | +8.1% | 多轮对话 |
| SWE-bench Verified | +5.4% | 代码修复，基线已高，提升有限 |
关键发现：基线越低，Harness 优化空间越大。这意味着小模型 + 好 Harness，可能比大模型 + 差 Harness 更划算。
论文还做了 Harness-Model Co-Evolution：Harness 适配产生的轨迹同时作为 RL 训练信号，模型改进又反馈到下一轮 Harness 进化。两个优化方向互补——Harness 侧是非参数优化（改配置），Model 侧是参数优化（改权重）。
代价清醒
先说好的：MIT 协议、Python 3.12、CLI 一键安装、IM Gateway 支持飞书/Telegram/Slack/钉钉、Lab UI 可视化。这些是实打实能用的。
再说问题：
319 Star，Beta 阶段。 这不是 LangGraph（45K+ Star）或 CrewAI（30K+ Star）那种经过大规模验证的框架。论文数据漂亮，但生产环境是另一回事。
Bus factor 极低。 核心贡献者 2 人（zhao9797 13 commits，shuolucs 5 commits），其余都是 1 commit 的边缘贡献者。核心开发者一走，项目就悬。
Post-peak degradation。 论文自己承认：在 SWE-bench 上，Harness 进化到一定轮次后性能开始下降。进化不是越多越好，什么时候停是个开放问题。
9 维管线可能过度工程。 Hugo Bowne 在《Stop Overengineering Your Agent Harness》里说得直白：不是每个系统都需要完整的 9 维管线。"问你需要什么技术，平均答案是一长串；问你的系统实际需要什么，答案通常很短。"
2 个 Open Issue，0 个 Release。 仓库还在快速迭代中，API 可能随时变。现在上生产，等于给自己埋定时炸弹。
竞品生态位
| 框架 | 核心理念 | 适合谁 |
|---|---|---|
| LangGraph | 状态机编排 | 需要精确控制流程的团队 |
| CrewAI | 角色化多 Agent | 快速验证、内容流水线 |
| AutoGen | 多 Agent 对话 | 研究实验（微软已转入维护） |
| HarnessX | 行为可组合+自适应进化 | 愿意在 Harness 层投入的团队 |
HarnessX 的独特价值不在"又一个 Agent 框架"，而在它把 Harness 当一等公民。其他框架的 Harness 是隐式的、散落在代码各处的配置；HarnessX 的 Harness 是显式的、可组合的、可进化的类型对象。
谁该用
研究团队：Harness 进化 + Co-Evolution 是学术富矿，论文已经开了很多口子（泛化性、成本-性能权衡、跨模型族迁移）。
Agent 重度用户：如果你已经在 Claude Code / Codex 上深度定制了 CLAUDE.md、Skills、MCP Server——你已经在做 Harness Engineering，只是没有 HarnessX 的形式化框架。试试把你的经验迁移到 HarnessX 的 Processor 模型里。
暂时不该用的：需要生产级稳定性的团队。319 Star + Beta + 0 Release = 还没到上生产的时机。等 1.0 再看。
相关链接：
- GitHub 仓库：https://github.com/Darwin-Agent/HarnessX
- 论文：https://arxiv.org/abs/2606.14249
- Addy Osmani - Agent Harness Engineering：https://addyosmani.com/blog/agent-harness-engineering
- Lilian Weng - Harness Engineering for Self-Improvement：https://lilianweng.github.io/posts/2026-07-04-harness
- Hugo Bowne - Stop Overengineering Your Agent Harness：https://hugobowne.substack.com/p/stop-overengineering-your-agent-harness
暂无评论。