radixark创始人Chayenne Zhao分享的关于“Harness Engineering”的见解：关于所谓 harness engineering 里的 “渐进披露”“机械化约束” 等新概念，本质都是传统软件工程中单一职责原则、关注点分离、docs-as-code、左移约束等经典实践在 LLM 场景的迁移啥的。-----------------------今天我读了一篇关于“Harness Engineering”的长文——几十千字，几乎可以确定是 AI 写的。我的第一反应不是“哇，多么强大的概念啊”，而是“这些人除了给旧概念起新名字，还有别的想法吗？”

我一直对 AI 领域这种模式感到恼火——不断地重新包装已有概念。从 prompt engineering 到 context engineering，现在到 harness engineering。每隔几个月，就有人创造一个新术语，写一篇一万字的长文，穿插几篇大公司的案例研究，整个社区就开始热议。但如果你仔细看内容，每次都是同样的东西：

设计模型运行的环境——它接收什么信息，可以使用哪些工具，错误如何被捕获，会话间如何管理内存。自 ChatGPT 发布那天起，这些就存在了。仅仅因为有人——出于某种原因——给它取了一个新名字，它就不会变成一个全新的学科。

话虽如此，撇开抱怨，文章引用的研究和案例研究确实有价值——尤其是它们与我在 how-to-sglang 中构建的内容高度重合。因此，我想借此机会谈谈我自己实际犯过的错误。

先做些背景介绍。在 SGLang 社区，最常见的请求是 How-to 问题——如何在 8 个 GPU 上部署 DeepSeek-V3，当 gateway 无法访问 worker 地址时该怎么办，GLM-5 INT4 与官方 FP8 的差距是否显著。这些问题覆盖了极其广泛的技术领域，而且随着社区增长速度越来越快，我们越来越无法及时回复。所以我开始构建一个多代理系统来自动回答这些问题。

第一个想法当然是最天真的——构建一个全知的单一 Agent，把 SGLang 的文档、代码和使用手册全部塞进去，让它回答所有问题。

结果不行。

你不需要 harness engineering 理论也能解释原因——context window 并不是 RAM。你塞得越多，模型的注意力就越分散，答案就越差。一个试图同时理解量化、PD 解耦、diffusion 服务和硬件兼容性的 Agent，最终没有一个能理解得很深入。

我们最终采用的设计是多层次的子领域专家架构。SGLang 的文档本身就有自然的功能边界——高级功能、平台、支持的模型——手册按模型组织。我们把每个子领域变成独立的专家 Agent，由一个 Expert Debating Manager 负责接收问题、分解子问题、查阅 Expert Routing Table 激活合适的 Agent、并行解决，再合成答案。

回头看，这种设计几乎完美映射了 harness engineering 社区所倡导的模式。但在我构建它时，我根本不知道这些模式有名字，也不需要知道。

----渐进披露——我们没有把所有文档都塞入任何单一 Agent。每个领域专家只加载自己的领域知识，Manager 根据问题类型决定激活谁。我的直觉是，这种设计带来的提升远超过更换一个更强模型。你不需要知道这叫“渐进披露”，只需要尝试过“塞满一切”的方法一次，并看到它失败。

----仓库作为事实来源——整个工作流都在 how-to-sglang 仓库中。所有专家 Agent 从仓库里的 markdown 文件中获取知识，不依赖外部文档或口头协议。早期我们曾想写一个覆盖全部内容的 sglang-maintain.md，很快就发现行不通。OpenAI 的 Codex 团队也犯了同样的错误——他们尝试用单一超大 AGENTS.md，结果以可预见的方式腐化。你不需要看他们的博客，也会踩到这个地雷。这是经典的软件工程问题：“单体文档总是过时”，在 Agent 场景下后果更严重——过时文档不仅没人看，还会误导 Agent。

----结构化路由——Expert Routing Table 明确将问题类型映射到 Agent。关于 GLM-5 INT4 的问题会同时激活 Cookbook Domain Expert 和 Quantization Domain Expert。Manager 不会猜测，它遵循结构化索引。harness engineering 圈子称之为“机械化约束”，我称之为普通工程实践。

我并不是说 harness engineering 背后的理念不好。引用的研究可靠，SWE-agent 的 ACI 概念确实值得了解，Anthropic 的双 Agent 架构（初始化 Agent + 编码 Agent）对于任何做长周期任务的人都是有价值的参考。我觉得令人厌烦的是不断创造新词——把已有的工程常识包装成新学科，再制造“如果你不知道这个词，你就落后了”的焦虑。

Prompt engineering、context engineering、harness engineering——它们只是同一事物的不同面。下个月可能有人会提出 scaffold engineering 或 orchestration engineering，再写一篇引用同样 SWE-agent 论文的长文，社区又会进入新一轮放大循环。

我从 how-to-sglang 中真正学到的东西，不需要任何新词就能表述：

提供给 Agent 的信息应最小且精确，而非最大化。复杂系统应拆分为专业子模块，而非构建全知 Agent。所有知识必须存在仓库中——口头协议不存在。路由和约束必须是结构化的，而非交给 Agent 自行判断。反馈回路应尽可能紧密——我们目前使用日志系统记录每个查询的完整推理链，并开始使用 Codex 进行 LLM 作为裁判的验证，但仍远未理想。

这些都不新。在传统软件工程中，这被称为关注点分离、单一职责原则、docs-as-code 和 shift-left 约束。我们只是将它们应用到 LLM 工作环境中，有些人觉得这值得一个新名字。

我不知道这个领域还会产生多少新词。但我知道，至少到今天，我们从未通过更换更强的模型在 how-to-sglang 上实现质的飞跃。真正推动突破的，总是在环境层面的改进——更精确的知识划分、更好的路由逻辑、更紧密的反馈回路。不管你称它为 harness engineering、context engineering，还是根本不叫，它只是良好的工程实践，仅此而已。

有一个问题我至今没有弄明白：如果模型能力持续指数级增长，会不会有一天模型足够强大，能够自己构建环境？我在观察 OpenClaw 时就有这种困惑——它在一个月内从 40 万行增长到 100 万行，完全由 AI 自行驱动。谁构建了那个项目的环境？是人类，还是 AI？如果是 AI，那么我们今天讨论的设计原则，有多少在两年后会完全无关紧要？

我不知道。但至少到今天，在我能观察到的每一个真实实践实例中，这仍然是人类的工作——而且是最有价值的工作。

How I AI