智能体 Harness 的演进：从链、图到代码化
基于大语言模型的智能体框架（Harness）在过去几年经历了三次范式变迁。LinkedIn 工程团队回顾了从线性“链”到结构化“图”的演进：前者上手快但脆弱，后者通过显式控制流、多智能体协作和人在回路机制，把概率模型逐步推向生产级可靠。
从粘合代码到结构化框架
过去几年，基于大语言模型构建的智能体发生了根本性变化。最初只是用粘合代码拼凑的临时提示词，如今演变为所谓的“智能体 Harness”（agent harness，即围绕概率模型搭建的结构化执行框架）——它像脚手架一样包裹模型，让不确定的输出变得稳定、可观测、可上生产。
这种演进不是一步到位，而是被真实业务需求推着走。整个过程先后出现三种范式，每一种都反映了同一个问题：如何约束非确定性的智能，并把它落地成可靠的软件系统。
链式范式：把提示词串成流水线
最早的智能体系统是简单的线性工作流，也就是“链”。它直观、落地快：把一系列提示词串起来，上一步的输出喂给下一步。Harness 本身只是工具调用和对话记忆的粘合代码，LLM 被当作黑盒函数——文本进、文本出，外面包一层语法糖。
在 LinkedIn，早期的生成式 AI 智能体基于 LangChain 构建，是一个固定三步链：
- 路由（Routing）：分类步骤，判断查询是否在范围内，以及该交给哪个专门的 AI“专家”处理。
- 检索（Retrieval）：偏向召回的步骤，调用合适的工具（如必应网页搜索或 LinkedIn 内部 API）收集信息，为检索增强生成（RAG，即先查资料、再让模型作答）提供事实依据。
- 生成（Generation）：偏向精度的步骤，过滤并综合检索到的数据，形成通顺的最终答案。
这种结构构建部署都很快，但很脆弱。以 LinkedIn 经济图谱问答为例，整个工作流完全依赖上一步文本的保真度，上游一个错误会级联放大，把流程带偏——系统内部没有机制能系统性识别错误或自动修复。
这也体现了早期智能体“尽力而为”的特点：做出前 80% 的体验相对容易，但要达到生产环境的质量，还得靠严格评估、提示词调优和持续的工程投入反复打磨。
图范式：让控制流显式化
随着场景变复杂，线性链的局限和脆弱已难以忽视。开发者转向图——这是一种很自然的抽象方式，可以在工作流里加入分支、条件逻辑、并行执行和重试。
在图式 Harness 中，节点表示任务（LLM 调用、工具调用、验证等），边控制流转。从线性到图的转变，和当年数据管道、分布式系统的演进如出一辙。
图系统的关键创新不只是“能分支”，而是让控制流变得显式、可声明。开发者不再把逻辑隐式塞进提示词或代码，而是定义一份可查看、可修改、可推理的执行计划。LLM 可以借助图结构，在动态环境里路由并执行复杂的长耗时任务。
对许多复杂任务来说，单体智能体已不再可行。图系统催生了多智能体架构：由顶层编排器管理任务流和依赖关系。多智能体协作需要成熟协议来支撑智能体之间的异步通信，例如 A2A 和 ACP（后者最终并入 A2A）。
受限于智能体自身的推理能力，“人在回路”（HITL，human-in-the-loop，即在关键节点让人参与）必不可少。智能体并非完全自主，而是在关键决策点向人寻求澄清、反馈或批准，在自主性与可控性之间取得平衡。
在 LinkedIn，团队复用现有的 LinkedIn 消息系统来做编排和智能体间通信，以处理长耗时任务——把任务拆成消息序列，保证严格的“先进先出”（FIFO）投递和无缝的消息历史查找。这套基础提供了：
- 并行能力：通过多条消息线程实现。
- 弹性：复用已有的持久重试和最终投递机制。
- 灵活的执行模式：智能体可以一次性返回结果、同步流式输出，或跨多条消息异步流式输出。
图式工作流用 LangGraph 实现，带来几项关键能力：
- 条件执行：根据中间结果路由、重新路由任务。
- 重试和回退：系统能从故障中优雅恢复。
- 状态管理：不再只有文本，整个流程会维护结构化的中间数据。
- 显式验证：包括模式检查、业务规则或辅助模型，避免盲目信任 LLM 的输出。
这些智能体还需要更强的记忆能力，能从用户交互中持续学习，支撑越来越个性化、自适应的体验。在分布式多智能体架构之上，LinkedIn 把认知记忆本身设计成一个独立智能体，供应用智能体集成。
这些创新支撑了 Hiring Assistant 的发布与后续迭代——这是 LinkedIn 首个面向招聘人员的 AI 智能体。招聘人员可以把找候选人、筛选申请人等耗时任务委托给它，把精力留给更具策略性、更需要人的核心工作。
图范式的瓶颈
图虽然比链显著扩展了智能体能处理的任务复杂度，但本质上仍是由人预先定义好工作流的自动化程序。工作流和状态空间一旦变复杂，开发者就得手写大量故障恢复、校验规则和边界异常处理，最终的流程定义与评测框架容易变得脆弱、繁琐、难以维护。这种僵化性也决定了图范式不适合那些无法被清晰表达为确定性工作流的任务。
代码范式：让执行成为一等公民
智能体系统最近的一次重大突破，是把代码而非提示词作为推理的主要媒介。系统不再只是让模型用自然语言“思考”一个复杂问题，而是让编码 Harness 在沙箱环境里生成、执行并优化代码。这里的 Harness 可以理解为智能体的运行框架与外壳。
这打破了一个根本局限：开发者不再需要预先设计复杂工作流，而是让智能体通过生成具备可验证输出的代码，自行“寻找”解决方案。这类 Harness 通常自带规划、任务委派、记忆访问、Token 管理与压缩等工具。
大模型的自然语言输出具有概率性，在后续验证之前本质上是不可靠的；代码则是确定性的——要么通过编译、运行并输出正确结果，要么直接运行失败。这种“通过或失败”的确定性提供了紧密的反馈回路，对大幅提升系统可靠性至关重要。
为保障安全和正确性，该架构包含四个核心组件：
- 执行沙箱：一个受控的隔离环境，生成的代码可以在其中安全运行。
- 埋点与日志：捕获代码执行期间的所有输出、错误和中间状态，方便后续排查问题。
- 验证 Harness：通过单元测试、断言或检查规则，自动验证生成代码的输出是否符合预期。
- 迭代优化循环：智能体识别到失败后，系统地修改生成的代码并自动重试，直到满足正确性要求。
在 LinkedIn，我们用这套方法构建了一个内部工具，让开发者、产品经理、数据科学家甚至业务运营人员都能向智能体提出自然语言分析问题，由智能体基于平台聚合数据和业务洞察给出答案。该智能体运行在现有的隐私、权限、安全框架内，遵循基于角色和用途的数据访问规则，在输出内容上叠加自动化合规审查，并通过获批的合规基础设施路由模型交互。
具体来说，智能体会把用户查询转换成声明式 SQL（说清楚要什么结果）和命令式 Python（一步步写清怎么做）代码的组合，在样本数据上执行，再按隐私、可见性和合规等严格约束验证输出，循环迭代直到满足所有正确性要求。
采用基于代码的方案缩短了上线时间，因为不必再费劲定制提示词、工具、工作流图和评估调优。最终系统不仅更可靠，可审计性和可复现性也显著提升。
智能体系统的架构最佳实践
无论你的系统处于哪个阶段——从简单的链式到复杂的编码 Harness——一些基本原则决定了它是健壮还是脆弱。
- 把 LLM 输出视为不可信输入：大模型输出具有概率性，必须在影响下游逻辑之前严格验证。可以先做 Schema 检查，套用业务与合规规则，或交给辅助模型复核，确认通过再继续流程。
- 把规划与执行解耦：让大模型提出计划，但在严格受控的软件框架内执行计划。这种分离能显著提升透明度和系统控制力。
- 提升可观测性：面对高度非确定性的复杂系统，看不见内部行为就无法调试。可观测性需要捕获每一步的执行状态、执行轨迹和验证结果等详细信息，同时对敏感信息做适当脱敏。
- 构建持续改进能力：智能体系统本质上是动态演进的，而非静态的。要建立反馈回路来捕获和分析失败，支持提示词、策略和程序记忆的演进，并在评估和仿真环境上持续投入。
如何选择合适的抽象范式
并非每个问题都值得引入图或编码 Harness 带来的运维复杂性。选择正确的抽象，本质上是在任务复杂度、可靠性要求、可解释性、延迟和成本之间做权衡。基本原则很简单：能用最简单的方式可靠解决问题，就用最简单的。
链式：适合范围明确的线性任务
对于范围明确的线性任务，链式方案通常就够了——单次或有限的提示词序列即可产生可接受的结果，例如撰写客服回复、总结文档、内容审核，或从可预测的输入中提取结构化数据。这类系统延迟最低、计算开销也小，因为它们把模型调用、编排开销和状态管理都降到了最少。对许多生产负载来说，链式仍然是最经济高效的选项，尤其是在需要快速迭代或大规模部署时。
图式：适合需要分支与状态的任务
当工作流需要条件分支、重试、工具调用或显式状态转换时，适合选择图方案。现实中的例子包括多步骤客服问题处理、企业 IT 自动化、合规流水线，或根据中间输出触发不同动作的入职系统。图提升了弹性和运维控制力，但也引入了额外延迟，通常需要多次 LLM 调用，从而推高服务成本和系统复杂性。它处于中间地带：比链式更可靠，但设计和运维成本更高。
编码型 Harness 最适合那些对准确性、可验证性和故障恢复能力要求极高的场景，例如软件工程智能体、金融分析系统、法律文件验证、科学工作流和基础设施自动化。这些场景的共同点是：输出结果可以被测试、编译、仿真或验证。代价也很明显：由于存在迭代推理循环、外部工具的执行与验证周期，这类系统通常会带来更高的计算和延迟开销。但在正确性远比速度或成本重要的地方，它们提供的保障也最强。
随着模型能力提升、成本下降，过度工程依然是一种常见的失败诱因。更复杂的抽象往往更快地推高计算开销、延迟和运维复杂度，而不是更快地改善业务成果。
真正的优势来自严谨地选择抽象层：部署能够满足可靠性、速度和成本要求的最简单系统。强大的工程组织靠的是优化每一分成本带来的能力收益，而不是把架构复杂度堆到最高。
结语
智能体系统的快速演进正在推动开发者角色发生根本转变：从“提示词设计师”走向“系统架构师”。在早期基于链式调用的 LLM 阶段，成功往往取决于构建完美提示词的技巧；当系统演进为复杂的图和代码 Harness 之后，重点就转移到了严谨的软件工程上——设计执行流程、管理状态与依赖，以及构建可靠的验证和恢复机制。
这一转变背后是一个更宏大的目标：从“尽力而为”转向“工程化可靠性”。早期系统把不可预测性视为固有约束并加以容忍；现代智能体 Harness 的要求更高——尽可能追求确定性，只在必要时引入可控的非确定性，并为故障定义清晰的模式和恢复路径。
这个过程标志着 AI 智能体从边缘实验走向生产级系统。真正新颖的地方不在于组件本身，而在于如何把概率模型集成进确定性框架。对正在构建 AI 编程产品、包括各类“氛围编程”工具的团队来说，这意味着 Harness 的设计能力会逐渐比提示词技巧更影响最终质量。
挑战与机遇在于：不要把这些系统当作神奇的黑盒，而要把它们当作软件系统来对待——与其它关键基础设施一样，它们需要同等严格的规范、精心的设计和一流的工程质量。
查看英文原文：https://www.infoq.com/articles/agentic-ai-architecture-harness-evolution/
关键要点
- 编码型 Harness 适合输出可被验证的高准确性场景，代价是更高的算力与延迟开销。
- 模型越强，越要警惕过度工程：复杂抽象常常先带来成本，而不是先带来收益。
- 选型原则是部署满足可靠性、速度和成本要求的最简系统，而非最大化架构复杂度。
- 开发者角色正从提示词设计转向系统架构，核心是把概率模型纳入确定性框架，并定义清晰的故障与恢复路径。