大模型时代模型能力从实验室走向真实场景真正考验的已经不只是参数、榜单和单点效果而是企业是否具备面向未来模型能力设计产品、管理复杂上下文、连接工具系统、建立评测闭环并在教育、翻译、办公、内容生产等真实场景中持续迭代的工程能力。这也是理解网易有道 AI 转型的一个重要切口。过去几年有道在大模型、多模态、语音、翻译和教育硬件等方向持续投入。但更关键的是它正在把这些能力沉淀为一套面向应用落地的产品工程方法模型是起点但真正决定 AI 产品能否长期服务用户向用户交付真实价值的关键同样包括模型之外的系统设计、场景理解和工程闭环。近期网易有道 CEO 围绕 Harness/Agent 分享了一组内部思考。他认为Agent核心是由“Model Harness”共同构成模型负责思考Harness 则负责让这种思考变得可理解、可协作、可复现、可长期运行和交付成果的系统。对于复杂 Agent 产品而言模型可能只完成一部分工作剩下支撑产品可靠运行的核心恰恰来自上下文管理、工具调用、评测体系、权限治理和循环控制等工程能力。关于Harness/Agent的讨论比较多总体上大家共同的看法是现在是通过Harness来做大模型创新应用的好时机但是Harness和以往的应用开发范式有较大不同需要用一些不同的方法才能做出好的产品沿用原有的思维方式可能事倍功半。本文从行业分享和内部实战中总结了一些最佳实践和大家探讨。先界定一下概念。所谓Harness马具/载体指的是模型之外、把模型包装成一个可用产品的那一整层工程上下文管理、工具、记忆、持久化状态、评测、循环控制、可观测性与权限治理。一个标准的说法是Agent Model Harness模型负责“思考”Harness负责让这份思考变得可理解、可协作、可复现、可长期运行。长程Agent对Harness的依赖超过它对任何单个模型的依赖。更强的模型并不会自动变成更可靠的Agent服务。简单来说对于一个复杂的Agent模型也许只完成20%的工作剩下80%、让产品持续可靠工作的基础是Harness。这正是标题“Harness即产品”的含义在大模型应用里团队真正在设计和迭代的产品往往不是一个个具体的功能而是这一整层Harness本身。下面七点是我看到的构建一个好的基于Harness产品的要点。1. 面向下一代模型能力设计产品很多团队一开始就犯一个错误围着模型今天的能力优化和打磨试图让功能更准、更快、更便宜结果产品上线没多久就被新模型直接替换。解决这一问题的一个办法是做一定的超前定位产品路线图不该只问模型今天能不能做更要问“半年后如果模型在规划、工具使用和长上下文上再上一个台阶我们如何抓住红利”。工程上可以先用强模型跑出效果再逐步尝试小模型替换业务上则优先选择会随着模型智能提升而不断放大价值的场景比如复杂决策场景、需要深度思考的功能、跨系统调度或者需要深入专业知识的产品。Claude Code负责人Boris Cherny在Lenny’s Podcast的访谈里把这件事讲得很清楚Claude Code一开始只是个小尝试团队是在“赌模型半年后的能力”——他们刻意按“模型将会变成什么样”、而不是“模型现在能做什么”来设计产品。当时他的判断是模型独立编程的能力正在快速上升交互方式因此必须从以人为主的自动补全auto-complete转向以Agent为主“模型能做到很多还没有产品接住的事…… 我们其实不必再做type-ahead了可以直接让Agent把所有代码都写出来。”这个赌注在2025年5月Opus 4发布时兑现产品随之取得巨大成功。他给出的两条产品原则也值得思考“别试图把模型框死”少用僵硬的编排多给工具和目标让模型自己想以及“押注更通用的模型”——在模型一夜之间就能改变能力边界的领域里能随模型一起变强的灵活方案往往胜过为当下定制的脚手架。2. 要做高智能产品不是所有AI功能都值得投入。一个简单的判断标准是如果这个问题主要靠规则、搜索和模板就能解决那它未必值得产品化如果它依赖模糊判断、跨文档理解、多步骤推理和人与系统之间的复杂协作那它才更适合为之开发大模型产品。一个考虑的角度是“类比一个需要资深员工处理的复杂任务切片”。如果你是产品负责人最应该优先筛选的场景不是流量最大而是单次任务价值最高、判断复杂度最高、人工成本最贵的那些。这类场景虽然起步看起来更难但一旦做通用户会把它当真正的生产力工具而不是新鲜一下的演示玩具。换个角度说任务切片越难、价值越高模型单独能交付的比例就越低当然最终能不能稳定上线恰恰取决于Harness建得好不好对模型能力的判断是否正确但总的来说把注意力集中在高智能产品方向上是成功可能性更大的。3. 有价值的Agent产品往往消耗较多tokens很多团队的第一直觉是“把token用量压到最低”但对真正困难的任务来说这往往是一上来就设定错了优化目标。对于高价值场景来说token消耗是创造价值的因此在一定范围内是越多越好。所以这类场景里正确的默认态度是舍得花——和上一点呼应单次任务价值越高、判断越复杂越不该在token上抠门。一个Agent任务跑下来累计输入token在数十万到数百万之间都是比较正常的。因此Harness的一个重要任务是让token的花费具有经济上的可核算性——能够统计和优化token的消耗使得该花的地方花充分不该花的地方足够节省。这个和公司的增长团队一定要量化计算ROI一样是团队一个必要的基本功。这里有一些重要的杠杆 一是提示词的缓存是团队要关注和优化的要点二是分层与路由——用强模型跑出比较好的效果后把简单节点下放给小模型也可以用批处理batch的方式跑可异步的批量任务、必要时做上下文重置来进一步节省开销。注意这些手段省的是无谓的浪费在高价值环节应该放开手脚放心大胆地花。4. 把上下文工程当成主任务上下文工程context engineering目的是让模型在某一时刻究竟知道什么、不知道什么、记住什么、遗忘什么而不是写更长、更巧妙的提示词。如果说Harness有一个心脏那就是上下文管理前面几点最终都要落到管理上下文内容这个动作上而不是简单地使用不断积累对话上下文的默认规则。至少要把上下文拆成几层系统规则、当前任务、检索知识、用户历史、长期偏好、工具结果。不同层应该有不同的优先级、生命周期和压缩方式见下图。Anthropic把上下文工程的目标概括成一句话找到“能最大化达成目标的、最小的一组高信号token”因为上下文是一种边际收益递减的有限资源。关于上下文工程的好文章不少比如这篇《Agent全面爆发万字长文详解上下文工程》5. 工具是给模型看的产品界面Agent调不好工具往往不是模型不聪明而是工具设计得不对。现在国内外主流模型的Agent能力都已经较强在绝大多数场景下都有有效地驱动设计良好的工具集合来工作所以在上下文工程之后工具的设计是团队应该聚焦的点。对于不熟悉这个方法的团队这需要一次观念升级你不只是写一个API给自己的前端或服务端调用而是在设计一个“模型可消费的能力单元”。如果工具过多、命名相似、参数含糊模型就容易误选如果返回结果冗长且噪音大还会进一步污染上下文。比较实用的做法是先收敛工具数量把高频业务动作做成少数几个高信号、强约束的工具其次使用严格的schema和结构化输出避免自由文本在节点之间传递错误指令最后为关键工具写清“什么时候该用、什么时候不该用、调用成功与失败分别长什么样”。Anthropic在工具使用文档里也强调影响调用效果最重要的因素之一就是工具描述本身。不少一线实践也指向同一组做法工具一旦超过二十来个模型就容易在相似工具间选错比如把“订单查询”和“物流查询”搞混同时避免“瑞士军刀式”的多功能工具改用单一职责、强schema的小工具并在真正调用前先做参数校验、把错误直接“回吐”给模型修正。6. 用评测驱动开发做Agent比较容易掉入的一个坑是做出“差不多”能工作的产品然后碰到问题反复手工调整但是按下葫芦浮起瓢陷入打地鼠的困境。这个时候团队缺乏的就是量化的评测办法。一个真正可上线的Agent必须有细分任务级的、量化的评测体系。评测至少要覆盖四层最终答案质量、工具调用正确率、流程完成率和安全样本通过率。更进一步来讲还应该有边界样本、对抗样本和真实线上日志回灌。一定要把“凭感觉”换成“看数据”。从实操角度Anthropic的《Demystifying Evals for AI Agents》是目前最权威的Harness/Agent评测指南同时也已经有多个开源的框架出现大家可以选择参考和使用。7. 默认从单Agent开始多Agent很容易让人兴奋因为看上去更像“组织协作”。但很多有经验的团队都建议先把单Agent做到极致只有当prompt逻辑过于复杂、工具集合拥挤、权限等级不同、任务目标天然分离时再拆成多Agent。原因很简单多Agent会带来handoff、状态同步、权限分层、成本叠加和调试复杂度。拆对了系统会更清晰拆错了只会让问题在更多节点里来回传递。真正值得拆的是那些边界清楚且目标不同的角色比如“分诊—执行—质检”“检索—分析—操作”或者“客服—退款—物流”。这件事社区里有一场很有代表性的争论CognitionDevin背后的团队写过《Don’t Build Multi-Agents》主张默认就用单Agent——多个Agent之间很难共享完整上下文、容易决策冲突对“写”类的强一致性任务比如写代码尤其脆弱而Anthropic在《How we built our multi-agent research system》里给出了反例在“读”类的开放式研究任务上主从式orchestrator-worker多智能体比单个Claude Opus 4高出90.2%但代价是token消耗约为普通对话的15倍。两边其实指向同一条分界线——任务偏“读”还是偏“写”、能不能共享上下文决定了该不该拆。小结你迭代的产品就是Harness把这七点连起来看它们其实是同一个工程的七个侧面超前定位定方向、高智能场景定取舍、舍得花token求价值、上下文管理是心脏、工具是手、评测是免疫系统、循环编排是骨架。模型会一代代变强而且只会越来越强——但更强的模型不会自动变成更可靠的Agent服务从demo到完整产品的鸿沟始终要靠Harness来填。所以做大模型应用真正在持续设计、打磨、积累壁垒的是这一整层Harness。模型是可更换的引擎Harness才是你自己造的车。
网易有道 CEO周枫谈 AI 原生应用的工程化路径 ：Harness即产品
大模型时代模型能力从实验室走向真实场景真正考验的已经不只是参数、榜单和单点效果而是企业是否具备面向未来模型能力设计产品、管理复杂上下文、连接工具系统、建立评测闭环并在教育、翻译、办公、内容生产等真实场景中持续迭代的工程能力。这也是理解网易有道 AI 转型的一个重要切口。过去几年有道在大模型、多模态、语音、翻译和教育硬件等方向持续投入。但更关键的是它正在把这些能力沉淀为一套面向应用落地的产品工程方法模型是起点但真正决定 AI 产品能否长期服务用户向用户交付真实价值的关键同样包括模型之外的系统设计、场景理解和工程闭环。近期网易有道 CEO 围绕 Harness/Agent 分享了一组内部思考。他认为Agent核心是由“Model Harness”共同构成模型负责思考Harness 则负责让这种思考变得可理解、可协作、可复现、可长期运行和交付成果的系统。对于复杂 Agent 产品而言模型可能只完成一部分工作剩下支撑产品可靠运行的核心恰恰来自上下文管理、工具调用、评测体系、权限治理和循环控制等工程能力。关于Harness/Agent的讨论比较多总体上大家共同的看法是现在是通过Harness来做大模型创新应用的好时机但是Harness和以往的应用开发范式有较大不同需要用一些不同的方法才能做出好的产品沿用原有的思维方式可能事倍功半。本文从行业分享和内部实战中总结了一些最佳实践和大家探讨。先界定一下概念。所谓Harness马具/载体指的是模型之外、把模型包装成一个可用产品的那一整层工程上下文管理、工具、记忆、持久化状态、评测、循环控制、可观测性与权限治理。一个标准的说法是Agent Model Harness模型负责“思考”Harness负责让这份思考变得可理解、可协作、可复现、可长期运行。长程Agent对Harness的依赖超过它对任何单个模型的依赖。更强的模型并不会自动变成更可靠的Agent服务。简单来说对于一个复杂的Agent模型也许只完成20%的工作剩下80%、让产品持续可靠工作的基础是Harness。这正是标题“Harness即产品”的含义在大模型应用里团队真正在设计和迭代的产品往往不是一个个具体的功能而是这一整层Harness本身。下面七点是我看到的构建一个好的基于Harness产品的要点。1. 面向下一代模型能力设计产品很多团队一开始就犯一个错误围着模型今天的能力优化和打磨试图让功能更准、更快、更便宜结果产品上线没多久就被新模型直接替换。解决这一问题的一个办法是做一定的超前定位产品路线图不该只问模型今天能不能做更要问“半年后如果模型在规划、工具使用和长上下文上再上一个台阶我们如何抓住红利”。工程上可以先用强模型跑出效果再逐步尝试小模型替换业务上则优先选择会随着模型智能提升而不断放大价值的场景比如复杂决策场景、需要深度思考的功能、跨系统调度或者需要深入专业知识的产品。Claude Code负责人Boris Cherny在Lenny’s Podcast的访谈里把这件事讲得很清楚Claude Code一开始只是个小尝试团队是在“赌模型半年后的能力”——他们刻意按“模型将会变成什么样”、而不是“模型现在能做什么”来设计产品。当时他的判断是模型独立编程的能力正在快速上升交互方式因此必须从以人为主的自动补全auto-complete转向以Agent为主“模型能做到很多还没有产品接住的事…… 我们其实不必再做type-ahead了可以直接让Agent把所有代码都写出来。”这个赌注在2025年5月Opus 4发布时兑现产品随之取得巨大成功。他给出的两条产品原则也值得思考“别试图把模型框死”少用僵硬的编排多给工具和目标让模型自己想以及“押注更通用的模型”——在模型一夜之间就能改变能力边界的领域里能随模型一起变强的灵活方案往往胜过为当下定制的脚手架。2. 要做高智能产品不是所有AI功能都值得投入。一个简单的判断标准是如果这个问题主要靠规则、搜索和模板就能解决那它未必值得产品化如果它依赖模糊判断、跨文档理解、多步骤推理和人与系统之间的复杂协作那它才更适合为之开发大模型产品。一个考虑的角度是“类比一个需要资深员工处理的复杂任务切片”。如果你是产品负责人最应该优先筛选的场景不是流量最大而是单次任务价值最高、判断复杂度最高、人工成本最贵的那些。这类场景虽然起步看起来更难但一旦做通用户会把它当真正的生产力工具而不是新鲜一下的演示玩具。换个角度说任务切片越难、价值越高模型单独能交付的比例就越低当然最终能不能稳定上线恰恰取决于Harness建得好不好对模型能力的判断是否正确但总的来说把注意力集中在高智能产品方向上是成功可能性更大的。3. 有价值的Agent产品往往消耗较多tokens很多团队的第一直觉是“把token用量压到最低”但对真正困难的任务来说这往往是一上来就设定错了优化目标。对于高价值场景来说token消耗是创造价值的因此在一定范围内是越多越好。所以这类场景里正确的默认态度是舍得花——和上一点呼应单次任务价值越高、判断越复杂越不该在token上抠门。一个Agent任务跑下来累计输入token在数十万到数百万之间都是比较正常的。因此Harness的一个重要任务是让token的花费具有经济上的可核算性——能够统计和优化token的消耗使得该花的地方花充分不该花的地方足够节省。这个和公司的增长团队一定要量化计算ROI一样是团队一个必要的基本功。这里有一些重要的杠杆 一是提示词的缓存是团队要关注和优化的要点二是分层与路由——用强模型跑出比较好的效果后把简单节点下放给小模型也可以用批处理batch的方式跑可异步的批量任务、必要时做上下文重置来进一步节省开销。注意这些手段省的是无谓的浪费在高价值环节应该放开手脚放心大胆地花。4. 把上下文工程当成主任务上下文工程context engineering目的是让模型在某一时刻究竟知道什么、不知道什么、记住什么、遗忘什么而不是写更长、更巧妙的提示词。如果说Harness有一个心脏那就是上下文管理前面几点最终都要落到管理上下文内容这个动作上而不是简单地使用不断积累对话上下文的默认规则。至少要把上下文拆成几层系统规则、当前任务、检索知识、用户历史、长期偏好、工具结果。不同层应该有不同的优先级、生命周期和压缩方式见下图。Anthropic把上下文工程的目标概括成一句话找到“能最大化达成目标的、最小的一组高信号token”因为上下文是一种边际收益递减的有限资源。关于上下文工程的好文章不少比如这篇《Agent全面爆发万字长文详解上下文工程》5. 工具是给模型看的产品界面Agent调不好工具往往不是模型不聪明而是工具设计得不对。现在国内外主流模型的Agent能力都已经较强在绝大多数场景下都有有效地驱动设计良好的工具集合来工作所以在上下文工程之后工具的设计是团队应该聚焦的点。对于不熟悉这个方法的团队这需要一次观念升级你不只是写一个API给自己的前端或服务端调用而是在设计一个“模型可消费的能力单元”。如果工具过多、命名相似、参数含糊模型就容易误选如果返回结果冗长且噪音大还会进一步污染上下文。比较实用的做法是先收敛工具数量把高频业务动作做成少数几个高信号、强约束的工具其次使用严格的schema和结构化输出避免自由文本在节点之间传递错误指令最后为关键工具写清“什么时候该用、什么时候不该用、调用成功与失败分别长什么样”。Anthropic在工具使用文档里也强调影响调用效果最重要的因素之一就是工具描述本身。不少一线实践也指向同一组做法工具一旦超过二十来个模型就容易在相似工具间选错比如把“订单查询”和“物流查询”搞混同时避免“瑞士军刀式”的多功能工具改用单一职责、强schema的小工具并在真正调用前先做参数校验、把错误直接“回吐”给模型修正。6. 用评测驱动开发做Agent比较容易掉入的一个坑是做出“差不多”能工作的产品然后碰到问题反复手工调整但是按下葫芦浮起瓢陷入打地鼠的困境。这个时候团队缺乏的就是量化的评测办法。一个真正可上线的Agent必须有细分任务级的、量化的评测体系。评测至少要覆盖四层最终答案质量、工具调用正确率、流程完成率和安全样本通过率。更进一步来讲还应该有边界样本、对抗样本和真实线上日志回灌。一定要把“凭感觉”换成“看数据”。从实操角度Anthropic的《Demystifying Evals for AI Agents》是目前最权威的Harness/Agent评测指南同时也已经有多个开源的框架出现大家可以选择参考和使用。7. 默认从单Agent开始多Agent很容易让人兴奋因为看上去更像“组织协作”。但很多有经验的团队都建议先把单Agent做到极致只有当prompt逻辑过于复杂、工具集合拥挤、权限等级不同、任务目标天然分离时再拆成多Agent。原因很简单多Agent会带来handoff、状态同步、权限分层、成本叠加和调试复杂度。拆对了系统会更清晰拆错了只会让问题在更多节点里来回传递。真正值得拆的是那些边界清楚且目标不同的角色比如“分诊—执行—质检”“检索—分析—操作”或者“客服—退款—物流”。这件事社区里有一场很有代表性的争论CognitionDevin背后的团队写过《Don’t Build Multi-Agents》主张默认就用单Agent——多个Agent之间很难共享完整上下文、容易决策冲突对“写”类的强一致性任务比如写代码尤其脆弱而Anthropic在《How we built our multi-agent research system》里给出了反例在“读”类的开放式研究任务上主从式orchestrator-worker多智能体比单个Claude Opus 4高出90.2%但代价是token消耗约为普通对话的15倍。两边其实指向同一条分界线——任务偏“读”还是偏“写”、能不能共享上下文决定了该不该拆。小结你迭代的产品就是Harness把这七点连起来看它们其实是同一个工程的七个侧面超前定位定方向、高智能场景定取舍、舍得花token求价值、上下文管理是心脏、工具是手、评测是免疫系统、循环编排是骨架。模型会一代代变强而且只会越来越强——但更强的模型不会自动变成更可靠的Agent服务从demo到完整产品的鸿沟始终要靠Harness来填。所以做大模型应用真正在持续设计、打磨、积累壁垒的是这一整层Harness。模型是可更换的引擎Harness才是你自己造的车。
