千问 C 端 Agent Harness 思考与实践
朱达 · 阿里巴巴 MOS 实验室负责人 · 2026.06.07
CCF YOCSEF 杭州 · 技术论坛"基模与 Agent：智能系统的边界之争、评估之变与进化之路"
"我应该属于务实派。前面大家关注的是模型怎么突破理论上限，我们要做的是一个很务实的事情——如何基于千问模型去服务千万甚至上亿的用户。"
千问任务助理：务实派的一线实践
Background：从 Manus 的爆火到千问自研 Agent
2025 年初，Manus 的爆火让行业看到了通用 Agent 的产品可能性。千问团队随即启动了自研通用智能体的项目，希望在阿里做一个能帮用户解决各种复杂问题的通用 Agent，并且真正做到大用户规模。
2025 年三四月份，国内涌现出大量类似产品和 Demo，但最终到年底能真正上线的产品寥寥无几。
千问团队在 2026 年 1 月正式上线了通用复杂任务 Agent（千问 App 对话框上方的"胶囊"入口），并将其打磨经验总结为"多快好省"四字方法论。
"多快好省"：Agent 产品化的四个维度
像做电商一样做 Agent——关键能力也是"多快好省"。
多：支持各种复杂任务类型。信息搜集、研究分析、生活服务、办公协作、代码开发——不是做一个垂直 workflow，而是一个通用 Agent 同时支持所有类型。团队设计了通用的规划与反思能力，结合 Agent 框架的分层协作：通用规划层处理复杂编排，垂直 Agent 处理专业领域。同时通过上下文经验注入不断总结失败经验，实现 Agent 的自我进化。
快：执行速度对得上交付质量。团队的理念是"执行时间应该对得上交付质量"——执行 5 分钟、10 分钟或半小时，交付质量应该有明显阶梯提升。关键优化手段包括模型选型的效果/性能 trade-off、任务并行化执行、以及"链路固化"——当 Agent 首次遇到某类任务时需要大量反思和规划，但积累经验后可以复用，甚至将执行路径固化为代码。最终执行时间降至初始的 1/3。
好：最高的交付质量。工业界最难的不是"怎么做好"，而是"怎么定义好"。朱达举了一个例子：搜集中国从秦朝到清朝的所有钱币种类——精确数量可能超过 1000 种，包含大量冷门品种。普通 Agent 找到十几种就会停止工作（上下文溢出或"自认为够了"）。模型搞不定的，就必须通过搜索范式优化、上下文管理等工程手段去解决。
省：Token 消耗只有海外产品的 1/10。产品免费提供给用户，成本控制是生命线。团队的做法是：减少模型调用（该用时用、不该用时不用）、让模型写代码替代重复推理、缓存优化、链路固化。最终在达到与海外产品相当效果的同时，Token 消耗仅为其 1/10 甚至更少。
"到了今年，更好的模型出来后，发现很多之前的脚手架并不需要了。这是我们的教训——随着基模进步，很多配套工作可能不再必须。但这些经验又会帮助我们在更好的基模上达到更好的效果。"
主动服务：从被动响应到精准预判
千问在 C 端面临一个现实问题：用户不会经常主动与 AI 交互，但团队希望千问能更多地帮助用户、提升互动粘性。解决方案是主动服务。
一个真正的私人助理，不是"我总去问我的助理"，而是助理了解你的一切——了解你的上下文、兴趣、需求，主动给你服务、主动给你推送。这意味着 Agent 从"被动响应"进化到"精准预判"。
架构上，主动服务的 Agent 需要具备四大组件：User Memory（了解用户画像）、Environment（感知外部环境变化）、Task System（自主管理任务）、以及 Assistant（综合决策并主动触达）。
三大核心挑战
1. 环境感知与事件建模：真实世界不断发生各种事件——参加会议、收到消息、天气变化。如何对这些事件建模？每个用户感兴趣的事件都不一样，模拟环境需要大量工程投入来获取和处理信息流。
2. 低成本感知方案：如果 Agent 不断感知环境、不断推理，算力承受不了，用户也不会为此付高昂费用。解决方案是：只有在特定条件触发时才调用大模型做推理，大部分时候用低成本方法处理。
3. "情商"：主动服务最难的一环：被动回答容易——用户已经说了要什么，答得好差而已。但主动说话非常讲究：说多了用户觉得打扰；涉及隐私信息（比如用户之前提到的疾病），推荐餐厅时提醒"这家太辣，你之前……"——看起来合理，但用户会认为 AI 过度利用了隐私。
"我们现在大量训练模型做问答——有问题就回答。但很少训练模型怎么'主动发起话题'。怎么主动跟人交流、发起对话，其实更难——这真的需要很高的情商。我们现在甚至认为，这可能需要在基模层面就具备这种能力。"
从 Harness Engineering 到 AIWare Engineering
Prompt Eng. → Context Eng. → Harness Eng. → AIWare Eng.
Agent Harness 工程全景框架
两年前是 Prompt Engineering，一年前强调 Context Engineering，今年最火的概念则是 Harness Engineering——把基模之外的一切都纳入工程体系。朱达引用了 Andrej Karpathy 的框架，将 Harness 分为七大模块：
- O Observability & Operations — 追踪、成本延迟监控、故障诊断、可靠性保障
- E Execution Environment & Sandbox — 安全沙箱、资源边界、执行基座
- T Tool Interface & Protocol — 工具模式、协议层、路由
- C Context & Memory Management — 注意力管理、会话状态、长期记忆
- L Lifecycle & Orchestration — 单/多 Agent 协调、任务流水线
- V Verification & Evaluation — Benchmark、就绪评估、回归反馈
- G Governance & Security — 权限管控、策略执行、安全护栏
核心观点：在应用场景下，把 Harness 做好给整体 Agent 效果的收益，可能高于去优化模型本身。
回望历史：1968 年的"软件危机"
朱达用计算机发展史做了一个类比：大模型 = CPU（最底层的计算能力），Agent/OpenCLAW = 操作系统（管理和调度 CPU），Harness = 系统调用层。
但朱达提出了一个新观点——1968 年的"软件危机"才是真正的关键节点。当年 CPU、操作系统、C 语言出来后，大家觉得计算机问题已经解决了。但随后发现根本不是这样——出现了各种搞不定的软件问题。
"为什么搞不定？核心是计算机不是解决代码问题，而是解决人的问题。涉及到人的预期、项目管理、团队组织——这比纯技术问题复杂得多。我们现在做 AI 也是一样。Harness Engineering 的下一步，应该是 AIWare Engineering——怎么真正把人和 AI 结合在一起。"
人类进化的启示：低功耗，够用就行
朱达用人类进化史做了一个类比：7 万年前人类进化出语言、大脑容量增加。但此后——5000 年前文字出现、1000 年前造纸术、500 年前印刷术、100 年前无线电、40 年前互联网——人类大脑容量再也没有增加过。
后面这些进步在干什么？信息能保存、能传递、能更快地交流、人与人的协作方式更高效。本质上不就是"上下文工程"吗？
"从大模型角度思考：模型不是不能做到更精准，但这个 ROI 划算吗？也许我们用更低功耗、更好的方法（Harness），也能大概达到更高模型的效果——而从整个社会发展来说，这更合适。基模 + Harness，最终形成一个合理的状态。"
务实派的核心判断
- 模型越强越好，但搞不定的靠工程 ——Agent 的价值在于补齐模型短板，而非取代模型进步
- "多快好省"是 C 端 Agent 的核心能力 ——通用性、速度、质量、成本缺一不可
- 主动服务需要"情商" ——这可能需要在基模层面解决，不仅是后训练或 PE 的问题
- Harness 短期收益高于优化模型 ——但随着基模进步，很多脚手架会被淘汰
- 下一站是 AIWare Engineering ——不只是技术问题，是"人 + AI"的组织方法论
- 自然规律：低功耗，够用就行 ——基模 + Harness 的合理均衡，才是可持续的终局