网易有道CEO周枫：一张图，七个要点，读懂"Harness思维
周枫开篇即给出一个尖锐判断：更强的模型并不会自动变成更可靠的 Agent 服务。 在 Agent = Model + Harness 这个等式中，模型负责"思考"，Harness 负责让思考变得可理解、可协作、可复现、可长期运行。对于一个复杂的 Agent，模型也许只完成 20% 的工作，剩下 80% 让产品持续可靠的基础——上下文管理、工具、记忆、持久化状态、评测、循环控制、可观测性与权限治理——全都是 Harness。
这正是标题"Harness 即产品"的核心：团队真正在设计和迭代的，不是一个个功能，而是这一整层工程本身。
以下是七个要点，以及我作为前端工程视角的补充解读。
1. 面向下一代模型能力设计产品
最常见的错误是围着模型今天的能力打磨，结果产品上线没多久就被新模型直接替换。
周枫建议做"超前定位"：产品路线图不该只问模型今天能不能做，更要问"半年后模型能力再上一个台阶，我们如何抓住红利"。工程上先用强模型跑效果，再逐步尝试小模型替换；业务上优先选择会随模型智能提升而不断放大价值的场景。
Claude Code 负责人 Boris Cherny 在 Lenny's Podcast 中的访谈是一个经典案例：团队刻意"赌模型半年后的能力"，按"模型将会变成什么样"而非"现在能做什么"来设计产品。他们判断模型独立编程能力正在快速上升，交互方式必须从 auto-complete 转向 Agent 为主——"我们其实不必再做 type-ahead 了，可以直接让 Agent 把所有代码都写出来"。这个赌注在 2025 年 5 月 Opus 4 发布时兑现。
Boris 给出的两条原则值得反复品味："别试图把模型框死"（少用僵硬编排，多给工具和目标让模型自己想），以及**"押注更通用的模型"**（能随模型一起变强的灵活方案胜过为当下定制的脚手架）。
工程视角补充：这和前端框架的演进逻辑一致——React 当年胜出不是因为它"今天更好用"，而是因为它押注了"组件化 + 声明式"这个会随生态成熟而持续放大的方向。Agent 产品的设计同样需要这种"赌方向"的能力。
2. 要做高智能产品
不是所有 AI 功能都值得投入。判断标准很简单：如果问题主要靠规则、搜索和模板就能解决，那它未必值得产品化；如果它依赖模糊判断、跨文档理解、多步骤推理和复杂协作，才更适合开发大模型产品。
周枫给出的筛选角度是**"类比一个需要资深员工处理的复杂任务切片"**——优先选单次任务价值最高、判断复杂度最高、人工成本最贵的场景。这类场景起步更难，但一旦做通，用户会把它当生产力工具而非演示玩具。
工程视角补充：这是对"什么值得做 Agent"的最务实回答。很多团队一上来想做"智能客服"这种看起来流量大的场景，结果发现规则引擎就能搞定 80%。真正值得 Agent 化的，是那些当前需要人去跨系统查、判断、协调的高价值切片。
3. 有价值的 Agent 产品，往往消耗较多 tokens
很多团队第一直觉是"把 token 用量压到最低"，但对高价值任务来说，这往往一开始就设定错了优化目标。token 消耗是创造价值的，一定范围内越多越好。一个 Agent 任务跑下来累计输入 token 在数十万到数百万之间都算正常。
Harness 的重要任务是让 token 花费具有经济上的可核算性——能统计和优化消耗，该花的花充分，不该花的足够节省。关键杠杆包括：提示词缓存、分层路由（强模型跑效果后简单节点下放小模型）、批处理跑异步任务、必要时做上下文重置。
工程视角补充：这和性能优化一个道理——不要过早优化。先让价值跑通，再用可观测性工具定位真正的浪费点。token 经济学本质上是 Agent 时代的性能工程。
4. 把上下文工程当成主任务
上下文工程（context engineering）的目的，是让模型在某一时刻究竟知道什么、不知道什么、记住什么、遗忘什么，而不是写更长更巧妙的提示词。如果说 Harness 有一个心脏，那就是上下文管理。
周枫建议至少把上下文拆成几层：系统规则、当前任务、检索知识、用户历史、长期偏好、工具结果。不同层有不同的优先级、生命周期和压缩方式。Anthropic 把目标概括成一句话：找到"能最大化达成目标的、最小的一组高信号 token"，因为上下文是边际收益递减的有限资源。
工程视角补充：上下文管理本质上是一种"内存管理"——和操作系统的虚拟内存、页面置换是同一类问题。系统规则是常驻内核，当前任务是工作集，检索知识是按需加载的页面，长期偏好是持久化存储。理解了这个类比，很多上下文工程的最佳实践就不言自明了。
5. 工具是给模型看的产品界面
Agent 调不好工具，往往不是模型不聪明，而是工具设计得不对。
这里需要一次观念升级：你不只是写一个 API 给前端调用，而是在设计一个**"模型可消费的能力单元"**。工具过多、命名相似、参数含糊，模型就容易误选；返回结果冗长且噪音大，会进一步污染上下文。
实用做法：先收敛工具数量，把高频业务动作做成少数几个高信号、强约束的工具；使用严格的 schema 和结构化输出；为关键工具写清"什么时候该用、什么时候不该用"。一线实践表明，工具一旦超过二十来个，模型就容易在相似工具间选错。避免"瑞士军刀式"多功能工具，改用单一职责、强 schema 的小工具，并在调用前做参数校验。
工程视角补充：工具设计其实就是"为非人类用户设计 API"。传统 API 设计给人看，文档写给人读；Agent 工具设计给模型看，schema 和描述就是"文档"。好的工具描述，就像好的函数命名和 JSDoc——简洁、明确、无歧义。
6. 用评测驱动开发
做 Agent 容易掉入的坑：做出"差不多"能工作的产品，然后碰到问题反复手工调整，按下葫芦浮起瓢。团队缺乏的就是量化的评测办法。
一个真正可上线的 Agent，必须有细分任务级的、量化的评测体系，至少覆盖四层：最终答案质量、工具调用正确率、流程完成率、安全样本通过率。更进一步还应有边界样本、对抗样本和真实线上日志回灌。一定要把"凭感觉"换成"看数据"。
Anthropic 的《Demystifying Evals for AI Agents》是目前最权威的指南，同时已有多个开源框架可选。
工程视角补充：这就是 Agent 时代的测试金字塔。传统前端的单元测试→集成测试→E2E 测试，对应到 Agent 就是工具调用正确率→流程完成率→端到端答案质量。没有评测体系的 Agent 产品，就像没有测试覆盖的代码库——看起来能跑，但没人敢动。
7. 默认从单 Agent 开始
多 Agent 看上去更像"组织协作"，但很多有经验的团队建议先把单 Agent 做到极致。只有当 prompt 逻辑过于复杂、工具集合拥挤、权限等级不同、任务目标天然分离时，才拆成多 Agent。
原因很简单：多 Agent 会带来 handoff、状态同步、权限分层、成本叠加和调试复杂度。拆对了系统更清晰，拆错了只会让问题在更多节点里来回传递。
社区里有一场代表性争论：Cognition（Devin 背后团队）写《Don't Build Multi-Agents》，主张默认用单 Agent——多 Agent 之间难共享完整上下文、容易决策冲突，对"写"类强一致性任务尤其脆弱；而 Anthropic 在《How we built our multi-agent research system》里给出反例：在"读"类开放式研究任务上，主从式多智能体比单个 Claude Opus 4 高出 90.2%，但代价是 token 消耗约 15 倍。
两边指向同一条分界线：任务偏"读"还是偏"写"、能不能共享上下文，决定了该不该拆。
工程视角补充：这和微服务拆分的逻辑完全一致——单体先做到极致，只有当团队规模、部署节奏、技术栈差异真正成为瓶颈时才拆。过早拆微服务和过早拆多 Agent 犯的是同一个错误：用架构复杂度去解决本该用代码组织解决的问题。
小结：你迭代的产品，就是 Harness
七点连起来看，是同一个工程的七个侧面：
- 超前定位定方向
- 高智能场景定取舍
- 舍得花 token 求价值
- 上下文管理是心脏
- 工具是手
- 评测是免疫系统
- 循环编排是骨架
模型是可更换的引擎，Harness 才是你自己造的车。模型会一代代变强，但从 demo 到完整产品的鸿沟，始终要靠 Harness 来填。
最终思考：对于前端工程师而言，Harness 思维其实并不陌生——它就是"把 AI 模型当作一个强大但不可靠的运行时，围绕它构建完整工程体系"的思路。我们早已习惯为浏览器这个不可靠的运行时做 polyfill、做错误边界、做性能监控、做状态管理。Harness 做的是同样的事，只是运行时从浏览器变成了 LLM。理解了这一层映射，从前端到 Agent 工程的迁移路径就清晰了。