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 智能体。招聘人员可以把耗时的活儿交给它，比如寻找候选人、协助筛选申请人，自己腾出手来做更具策略性、更贴近人的核心工作。

时间一长，LinkedIn 意识到，单单一个能力强的模型，撑不起真正出色的智能体体验。智能体得懂领域知识，这些知识要以丰富的组织上下文为底子，还得能持续迭代优化。记忆能力因此变得必要：从交互中学习，让招聘人员得到日益个性化、自适应且实用的体验。

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

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

智能体系统最近一次大突破，是把代码而非提示词当作推理的主要媒介。复杂问题不再只是让模型用自然语言去“思考”，而是让编码 Harness 在沙箱里生成、执行并优化代码。

一个根本局限就此被打破：开发者不必预先设计复杂工作流，智能体自己通过生成带可验证输出的代码去“找”解法。这类 Harness 通常自带规划、任务委派、记忆访问、Token 管理与压缩等工具。

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

安全和正确性怎么保？该架构有四个核心组件。

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

• 埋点与日志：把代码执行期间的所有输出、错误和中间状态抓下来，便于事后排查。

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

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

在 LinkedIn，团队用这套方法做了个内部工具。开发者、产品经理、数据科学家乃至业务运营人员，都能向智能体提自然语言的分析性问题，智能体基于平台聚合数据与业务洞察给出答案。这个智能体跑在 LinkedIn 现有的隐私、权限、安全框架内，遵循基于角色和用途的数据访问规则，输出内容上叠加自动化合规审查，模型交互则通过获批的合规基础设施路由。

用户查询会被它转成声明式 SQL 与命令式 Python 代码的组合，在样本数据上执行，再按严格约束（隐私、可见性、合规检查都算）验证输出，循环迭代，直到所有正确性要求都满足。

走代码这条路，上线时间缩短了，因为不必费劲去定制提示词、工具、工作流图和评估调优。最终系统不光更可靠，可审计性和可复现性也明显提升。

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

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

• 把 LLM 输出当成不可信输入：大语言模型输出带概率性，在影响下游逻辑之前必须严格验证，绝不能在未经验证时相信文本输出。流程往下走之前，先上 Schema 检查、业务和合规规则，或者辅助模型。

• 让规划与执行解耦：大模型负责提出计划，执行则放在严格受控的软件框架里。这种分离很关键，透明度和系统控制力都能因此显著提升。

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

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

选择合适的抽象范式

引入图结构或编码Harness，运维上会更复杂，所以并非所有问题都值得这么干。抽象选得对不对，说到底是在任务复杂度、可靠性要求、可解释性、延迟和成本之间做权衡。原则很朴素：能可靠解决问题的最简单系统，就是该用的系统。

任务范围清楚、走线性的场景，链式方案通常够用——一次提示或有限的提示序列，就能给出可接受的结果。写客服回复、总结文档、做内容审核，或者从可预测的输入里抽取结构化数据，都属于这一类。这类系统延迟最低，算力开销也小，因为模型调用、编排开销和状态管理都被压到了最少。不少生产负载里，链式仍然是最省钱、最高效的选择，尤其是需要快速迭代或大规模部署的时候。

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

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

模型在进步，成本在下降，可过度工程的倾向依然是常见的失败诱因。更复杂的抽象，往往先带来算力开销、延迟和运维复杂性的快速上升，业务成果的改善却没那么快。

真正的优势来自严谨地挑选抽象层：部署能满足可靠性、速度和成本要求的最简单系统。工程组织强不强，不看架构复杂度堆到多高，而看每一分成本换回多少能力。

结语

智能体系统演进得快，开发者的角色也跟着发生了根本转变。从“提示词设计师”到“系统架构师”，这个职业转型正在发生。早期基于链式的LLM阶段，成败常常取决于写提示词的功夫。系统演变成复杂的图和代码Harness之后，重心就落到了严谨的软件工程上：设计执行流程、管理状态和依赖，还要搭建可靠的验证与恢复机制。

支撑这一转变的，是更大的目标：从“尽力而为”转向“工程化可靠性”。早期系统把不可预测当成固有约束，容忍它。现代智能体Harness的要求更高，凡是有可能的地方都追求确定性，只在必要时保留可控的非确定性，并且把故障模式和恢复路径定义清楚。

这个过程意味着，AI智能体已经从尖端边缘实验，变成了一流的生产级系统。新意不在组件本身，而在于概率模型是怎样被集成进确定性框架的。

挑战和机会都在这里：别把这些系统当成神奇的黑盒，要把它们当软件系统来对待——和其他关键基础设施一样，它们需要同等严格的规范、精心的设计、一流的工程质量。