核心要点
Harness 工程的定义：Harness 是编码 Agent 的「脚手架」，决定了如何组织模型、工具、上下文，以及如何协调多个 Agent 协作。核心组件三层：工具路由（智能选择工具）、上下文管理（压缩关键信息）、多 Agent 编排（协调 Agent 协作）。
底层模型差异已缩小到可互换程度：GLM-5.2 在 Agent 评测中得分仅比 Opus 4.8 低 1 个百分点，成本却只有其 1/5（ITHome，2026-07-07）。Claude Code 每日贡献 GitHub 约 10% 公开 commit（326K+/天），但开发者选择 Agent 的依据已从模型能力转向 Harness 设计。
Omnigent（Databricks 开源）是首个元 Harness：统一治理 Claude Code、Codex、Pi 等多个 Agent，标志着行业从「选择哪个 Agent」转向「如何编排多个 Agent」。
实践指南四步法：明确任务边界和工具集 → 设计上下文管理策略（分层存储/动态压缩/智能检索）→ 实现错误恢复机制 → 添加监控和可观测性。
简要回答
Harness 工程是编码 Agent 的脚手架，由工具路由、上下文管理、多 Agent 编排三大组件构成。2026 年底层模型差异已缩小到可互换，Harness 设计成为真正的差异化来源。
标准回答
一、Harness 工程的本质
Harness 是编码 Agent 的「脚手架」，决定了如何组织模型、工具、上下文，以及如何协调多个 Agent 协作。优秀的 Harness 设计可以让普通模型表现出色，而糟糕的 Harness 设计会让顶级模型频频出错。
三大核心组件：
工具路由：负责决定 Agent 在特定任务中应该调用哪些工具。朴素方案是把所有工具都暴露给模型，但实践表明会导致模型选择困难、调用错误、上下文污染。优秀设计实现智能路由：预筛选（根据任务类型预先筛选工具子集）、动态调整（根据上下文动态调整工具优先级）、错误重试（工具调用失败时自动重试或切换备选工具）。Claude Code 的工具预处理器是业界标杆，每次调用前预处理工具集，只保留与当前任务相关的工具。
上下文管理：最关键的层。编码任务的上下文包括代码库结构、依赖关系、历史修改、测试结果、文档说明等，总量远超模型上下文窗口限制。三个核心策略：分层存储（核心层/摘要层/外部层）、动态压缩（摘要压缩/选择性遗忘/滑动窗口）、智能检索（语义检索而非全量加载）。Claude Code 的上下文压缩算法是其领先竞品的核心优势。
多 Agent 编排：2026 年最热门方向。复杂编码任务通常需要多个 Agent 协作：架构设计、代码实现、测试验证、文档生成。核心挑战：任务分配、通信协议、冲突解决、结果合并。
二、底层模型差异已缩小
GLM-5.2 在 Agent 评测中得分仅比 Opus 4.8 低 1 个百分点，成本却只有其 1/5。Claude Code 每日贡献 GitHub 约 10% 公开 commit（326K+/天），2 月仅 4%。编码 Agent 已从实验性工具变成主流开发者日常选择，但开发者选择 Agent 的依据已从模型能力转向 Harness 设计。
三、元 Harness 的出现
Omnigent（Databricks 开源）是首个元 Harness，统一治理 Claude Code、Codex、Pi 等多个 Agent。元 Harness 不直接执行任务，而是治理多个 Harness，负责跨 Agent 的任务路由、负载均衡、故障恢复。标志着编码 Agent 赛道从「选择哪个 Agent」转向「如何编排多个 Agent」。
四、实践四步法
- 明确任务边界和工具集：不要试图让 Agent 处理所有任务，工具集越聚焦，Agent 表现越好。
- 设计上下文管理策略：核心任务信息保留在上下文，背景信息压缩为摘要，详细信息存储在外部可查询。
- 实现错误恢复机制：工具调用失败时自动重试、结果验证失败时回滚、检测到死循环时强制终止。
- 添加监控和可观测性：每步的输入输出、工具调用的成功率和延迟、上下文的使用率、错误的发生频率。
常见误区
⚠️ 常见踩坑
误区一：只比模型 benchmark，不看 Harness。 模型分数接近时，真正拉开差距的是工具路由、上下文压缩与错误恢复；只背模型名无法回答「为什么选 Claude Code」。
误区二：把多 Agent 当成默认架构。 简单线性任务用单 Agent + 良好上下文管理通常更稳；盲目上编排会放大延迟、成本与冲突面。
误区三：工具全量暴露给模型。 工具越多选择越差、上下文越脏；应按任务预筛选子集，并保留失败重试与备选切换。
追问
追问 1：工具路由的「动态路由」策略如何实现？与静态预筛选相比有哪些工程挑战？
题库专题：LangChain 中如何实现流式输出、条件分支与动态路由？动态路由策略的实现和工程挑战：
实现方式：1) 任务分类器——在用户请求到达 Agent 前，用轻量分类器（如 fine-tuned BERT）判断任务类型（代码审查/Bug修复/新功能开发等），根据类型动态选择工具子集。2) 上下文感知——根据当前上下文动态调整工具优先级，如检测到测试失败时优先暴露调试工具。3) 历史反馈——根据工具调用的成功率和延迟动态调整路由策略，失败率高的工具降低优先级，延迟高的工具在时间敏感任务中避免使用。
工程挑战：1) 分类器训练——需要大量标注数据，初始阶段可用规则引擎替代。2) 路由延迟——分类和路由决策会增加 50-100ms 延迟，时间敏感任务需权衡。3) 工具集变化——新工具加入时需要重新训练分类器或更新规则。4) 调试困难——动态路由使得问题定位更复杂，需要完善的路由日志和可观测性。
追问 2：多 Agent 编排中，如何解决 Agent 之间的冲突？举例说明。
题库专题：什么是 ReAct 模式？它如何解决 Agent 的推理与行动问题？多 Agent 编排中解决 Agent 冲突的三种策略：
1. 仲裁者模式：引入一个「仲裁 Agent」，当多个 Agent 的输出冲突时，由仲裁者综合各方信息做出最终决策。例如：架构 Agent 建议用微服务架构，实现 Agent 认为当前团队规模不适合微服务，仲裁 Agent 综合团队规模、项目复杂度、维护成本等因素，做出最终决策。
2. 投票机制：多个 Agent 对同一问题独立给出方案，通过投票（如多数投票、加权投票）选择最终方案。例如：三个 Agent 分别建议三种不同的数据库方案，通过投票选择得票最多的方案。加权投票可以根据 Agent 的历史准确率分配权重。
3. 分层决策：将决策分为不同层级，低层级冲突由相关 Agent 自行解决，高层级冲突由人类或更高层 Agent 解决。例如：代码风格冲突由代码 Agent 自行解决，架构冲突由架构 Agent 解决，跨模块冲突由编排层解决。
实际案例：Claude Code Agent Teams 采用「主 Agent + 子 Agent」模式，主 Agent 负责任务分解和协调，子 Agent 负责具体执行。当子 Agent 的输出冲突时，主 Agent 作为仲裁者做出最终决策。Codex 子代理采用「对等 Agent」模式，各 Agent 独立执行，通过消息队列协调，冲突时采用投票机制。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
