智能体Harness框架怎么演进：从链式编排到图与代码化

这几年，用大语言模型搭智能体的方式已经变了模样。早期只是拿粘合代码把提示词临时拼在一起，现在则发展出所谓智能体 Harness 框架，也就是结构化执行框架：以概率模型为核心搭一层脚手架，让模型输出稳定、过程可观测，达到生产可用水平。

变化不是一步到位的，而是随着真实业务需求一点点长出来的。这条路上先后冒出三种差别明显的范式，每种都对应着对“怎样管住不确定的智能、并把它变成可靠软件”更深一层的理解。

链式范式：提示词编排

最早的智能体系统就是一条简单的线性流程，业内叫“链”。它好懂、上手快，能迅速上线：把一串提示词首尾相接，上一步的输出直接喂给下一步。Harness 框架这时无非是工具调用和对话记忆的粘合代码，LLM 被当成黑盒函数——文本进去、文本出来，外面再裹点语法糖。

以 LinkedIn 为例，他们早期一个生成式 AI 智能体就建在 LangChain 上，是一个固定三步的链式流程：

1. 第一步是路由（Routing），做分类，判断问题是否落在范围内，该交给哪一位专门的 AI“专家”；第二步是检索（Retrieval），偏召回，调用合适的工具（比如必应网页搜索或 LinkedIn 内部 API）把特定信息捞回来，整理成一份档案，为检索增强生成（RAG）提供事实依据；第三步是生成（Generation），偏精度，对检索到的数据做过滤和综合，输出通顺的最终答案。

搭起来快、部署也快，可这种简单结构经不起折腾。整个流程（比如靠一串工具调用、基于 LinkedIn 经济图谱回答用户问题）完全押在前一步文本的保真度上。上游一出错就一路往下传，把整条流程带偏，系统里并没有内建机制去系统性地发现错误或自动修复。

这正反映了早期智能体产品“尽力而为”的路子：前 80% 的体验做出来不算慢，但要补上生产环境要求的最后那点质量，得靠严格评估、提示词打磨和持续工程投入反复迭代。

图范式：引入结构与控制

智能体系统的应用场景越来越复杂，线性链式方案天生的局限和脆弱就藏不住了。开发者转向图——一种很自然的抽象，能把分支、条件逻辑、并行执行和重试都塞进工作流。

在这种方案里，基于图的 Harness 框架拿节点代表不同任务（LLM 调用、工具调用或校验），拿边控制流向。从线性结构走到图，和数据管道、传统分布式系统的演进路线几乎一模一样。

图系统的关键创新不只是多了分支，而是把控制流做成显式、可声明的。逻辑不再隐式埋在提示词或代码里，开发者把它定义成一眼能看、能改、能理清的执行计划。于是有了推理循环控制流，LLM 可以在动态环境里借助图结构来路由、执行复杂的长耗时任务。

很多复杂任务已经不是一个单体智能体应用能扛的了。图系统催生了多智能体系统，由顶层智能编排器管任务流和依赖关系。转向多智能体，就需要成熟协议来支撑智能体之间的异步通信，比如 A2A 和 ACP（后者最终并入了 A2A）。

智能体自身的推理能力有限，“人在回路”（HITL）机制就少不了。它们并非完全自主，而是在关键决策点向人求澄清、收反馈或请求批准，在自主和可控之间找平衡。

在 LinkedIn，他们把编排和智能体间通信建在现有的 LinkedIn 消息系统上，用来处理长耗时任务——把任务拆成消息序列，保证严格的“先进先出”（FIFO）投递，消息历史也能无缝查找。这套底座带来三样东西：并行能力，靠多条消息线程实现；弹性，靠现成的持久重试和最终投递机制实现；灵活的执行模式，智能体可以一次性返回结果、同步流式输出，或者跨多条消息异步流式输出。

基于图的工作流由 LangGraph 落地，提供了几项关键能力，让系统更稳、复杂度更好管：

• 一是条件执行，能依据中间结果对任务重新路由；二是重试和回退，系统遇到故障可以从容恢复；三是状态管理，系统不再局限于文本，而是在整个流程中维护结构化的中间数据。

• 所谓显式验证，指的是模式检查、业务规则或者借助辅助模型来判断，目的是不盲目相信 LLM 给出的结果。

智能体还得有够强的记忆本领，能从和用户的交互里不断学习，时间一长就能支撑越来越个性化、能自适应、也真正好用的体验。基于分布式多智能体架构，LinkedIn 把认知记忆单独做成一个智能体，让应用智能体去集成它。这些创新促成了 Hiring Assistant 的发布以及后续的迭代，这是 LinkedIn 首个面向招聘人员设计的 AI 智能体。招聘人员可以把耗时的活儿交给 Hiring Assistant，比如寻找候选人和协助筛选申请人，自己则把精力放在更具策略性、更偏人际的核心工作上。

一路走来，LinkedIn 发现，要做出真正出色的智能体体验，光有一个能力强大的模型并不够。智能体得有深厚的领域知识，这些知识要以丰富的组织上下文为根基，还得能持续迭代优化。这就要求具备记忆能力，从交互中学习，给招聘人员带来越来越个性化、能自适应且实用的体验。

图虽然比链大幅扩展了智能体能处理的任务复杂度，可它说到底还是由人预先定义好工作流的自动化程序。工作流和状态空间越来越复杂，开发者肩上的压力也越来越大，得手动写大量故障恢复逻辑、校验规则和边界异常处理。最后流程定义和评测框架往往变得脆弱、繁琐、难以维护。这种僵化也让基于图的方法应付不了那些没法清晰表达成确定性工作流的任务。

代码范式：把执行当作一等原语

智能体系统最近一次重大突破，来自把代码而非提示词当成推理的主要媒介。做法不再是简单让模型用自然语言去“思考”复杂问题，而是让编码 Harness 在沙箱环境里生成、执行并优化代码。这就打破了一个根本局限：开发者不用再预先设计复杂工作流，智能体通过生成带可验证输出的代码，自己去“寻找”解法。这类 Harness 通常自带规划、任务委派、记忆访问、Token 管理与压缩等工具。

大模型的自然语言输出带有概率性，在进入后续验证步骤之前，本质上并不可靠。代码不一样，它是确定性的：要么通过编译、运行并输出正确结果，要么运行失败。这种非通过即失败的确定性形成了紧密的反馈回路，对大幅提升系统可靠性来说很关键。

该架构包含四个核心组件，用来保障安全和正确性：

• 执行沙箱：一个受控的隔离环境，生成的代码在其中可以安全运行。

• 埋点与日志：把代码执行期间的所有输出、错误和中间状态都捕获下来，方便后续排查问题。

• 验证 Harness：单元测试、断言或者检查规则，自动验证生成代码的输出是否达到预期。

• 迭代优化循环：智能体发现失败后，系统地修改生成的代码，并自动重试执行，直到满足正确性要求。

在 LinkedIn，团队用这套方法做了一个内部工具，开发者、产品经理、数据科学家甚至业务运营人员都能向智能体提自然语言的分析性问题，智能体基于平台聚合数据和业务洞察给出答案。该智能体运行在 LinkedIn 现有的隐私、权限、安全框架内，遵循基于角色和用途的数据访问规则，在输出内容上叠加自动化合规审查，模型交互则通过获批的合规基础设施路由。它把用户查询转换成声明式 SQL 和命令式 Python 代码的组合，在样本数据上执行，按严格约束（包括隐私、可见性和合规检查）验证输出，并循环迭代，直到满足所有正确性要求。

采用基于代码的方案缩短了上线时间，因为不必再费力定制提示词、工具、工作流图和评估调优。最终的系统不只更可靠，可审计性和可复现性也明显提升。

健壮的智能体 AI 架构最佳实践

不管你的智能体系统处在哪个阶段——从简单的链式到复杂的编码 Harness——系统是健壮还是脆弱，都由一些基本原则决定。

• 把 LLM 输出当成不可信输入：大语言模型的输出具有概率性，所以在它们影响下游逻辑之前必须严格验证，绝不能在未经验证的情况下信任文本输出。流程继续之前，要应用 Schema 检查、业务和合规规则或者辅助模型。

• 让规划与执行解耦：由大模型提出计划，但计划要在严格受控的软件框架内执行。这种分离很关键，它能显著提升透明度和系统控制力。

• 提升可观测性：一个复杂且高度非确定性的系统，如果看不到它的内部行为，就没法调试。强大的可观测性必须捕获详细信息，包括智能体每一步的执行状态、执行轨迹和验证结果，同时要对敏感信息做适当脱敏。

• 构建持续改进能力：智能体系统本质上是动态演进的，而非静态的。要构建强大的反馈回路来捕获和分析失败，支持提示词、策略和程序记忆的演进，并在评估和仿真环境上投入，持续提升系统性能。

选择合适的抽象范式

图方案或者编码Harness能解决不少问题，可运维上的麻烦也随之而来，并不是什么任务都值得付这个代价。挑哪种抽象，说到底是在任务有多复杂、可靠性要求多高、可解释性要多少、延迟和成本能承受多少之间做权衡。原则不复杂：能稳稳把问题解决掉的最简单那套系统，就是该用的。

任务范围清楚、路径线性的时候，链式方案一般够用——一次提示词调用，或者有限的几次串起来，结果就可以接受。写客服回复、给文档做摘要、内容审核，或者从格式固定的输入里抽取结构化数据，都属于这一类。这类系统通常延迟最低、算力花得也少，因为模型调用、编排开销和状态管理都被压到了最少。不少生产负载里，链式仍然是既省钱又高效的选项，要快速迭代或者大规模铺开时尤其如此。

一旦工作流里出现条件分支、重试、工具调用或者明确的状态切换，就该上图方案了。现实中的例子有：多步骤的客服问题处理、企业IT自动化、合规流水线，还有那种根据中间输出触发不同动作的入职系统。图带来了弹性和运维上的掌控力，代价是额外的延迟，而且往往要多次调用LLM，服务成本和系统复杂度跟着上去。它处在中间位置：比链式可靠，设计和运维却更费劲。

编码Harness则适合那些对准确性、可验证性、故障恢复能力要求极高的场合。软件工程智能体、金融分析系统、法律文件验证、科学工作流、基础设施自动化，都是例子——这些场景里生成的东西可以被测试、编译、仿真或者验证。迭代推理的循环、外部工具的执行和验证周期都在，计算和延迟开销通常更高。可要是正确性比速度和成本更要紧，它给出的保障也最强。

模型在进步，成本在往下走，可过度工程的毛病照样是常见的翻车原因。抽象越复杂，算力、延迟和运维复杂性涨得越快，业务成果却不会因此更快变好。

真正拉开差距的，是把抽象层选得严谨：部署那套刚好满足可靠性、速度和成本要求的最简系统。工程组织强不强，不看架构复杂度堆到多高，而看每一分成本换回多少能力。

结语

智能体系统跑得快，开发者的角色也跟着变了。从“提示词设计师”转向“系统架构师”，这个职业转型正在发生。早先链式LLM的阶段，做得好不好，常常看提示词写得精巧不精巧。系统一步步长成复杂的图和代码Harness之后，重心就落到了扎实的软件工程上：设计执行流程、管理状态和依赖，把验证和恢复机制做结实。

转向背后是个更大的目标：从“尽力而为”的心态，改成“工程化可靠性”。早期系统把不可预测当成绕不开的约束，也就忍了。现代智能体Harness要求不一样，凡是能确定的地方都追求确定性，非确定性只在必要时用，而且得可控，故障模式和恢复路径都要写清楚。

一路走下来，AI智能体从边缘地带的尖端实验，变成了生产级的一流系统。新意不在组件本身，而在于它们把概率模型嵌进确定性框架的方式。

挑战和机会都在这儿：别把这些系统当成神奇的黑盒，要把它们当软件系统看——跟其他关键基础设施一样，规范、设计、工程质量，一样都不能松。