智能体 Harness 从链到图再到代码化：三步演进怎么走

这几年，用大语言模型搭智能体的方式已经变了个样。早先只是拿粘合代码把提示词临时拼在一起，现在则长成了所谓的智能体 Harness 框架，也叫结构化执行框架：在概率模型外面架一层脚手架，让模型跑得稳、看得清，够得上生产级。

这种变化不是一夜之间发生的，而是一点点推进的，动力来自真实业务场景不断加码的需求。沿着这条线看，前后冒出过三种很不一样的路子，每种都对应着人们对“怎么管住不确定的智能、再把它做成靠谱软件”这件事更进一层的理解。

最早的智能体系统是围着简单的线性流程转的，大家管它叫“链”。这法子直白，落地也快，能迅速上线。做法就是把一串提示词接起来，上一步的输出喂给下一步，一路往下传。Harness 框架在那时候不过是工具调用、对话记忆的粘合代码，说到底还是把 LLM 当成黑盒函数：文本进、文本出，再撒点语法糖。

比如在 LinkedIn，我们早期的一个生成式 AI 智能体就是拿 LangChain 框架搭的固定三步链式流程：

1. 路由（Routing）：这是一个分类步骤，用来判断查询在不在范围内，以及该交给哪个专门的 AI“专家”去处理。
2. 检索（Retrieval）：这一步偏向召回，调用合适的工具（像必应网页搜索或者 LinkedIn 内部 API）把特定信息搜集起来，整理成一份档案，给检索增强生成（RAG）提供事实依据。
3. 生成（Generation）：这一步偏向精度，把检索到的数据过滤、综合，最后写成通顺的答案。

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

这正体现了早期智能体产品“尽力而为”的样子。最初 80% 的体验做起来比较快，可要补上生产环境要求的那最后一段质量，就得靠严格评估、提示词优化和持续工程投入，反复磨很多轮。

智能体系统的应用场景越铺越复杂，线性链式方案本身的局限和脆弱就藏不住了。开发者于是转向图——这是个很自然的抽象，能把分支、条件逻辑、并行执行和重试机制塞进工作流里。

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

图系统的关键创新不只是多了分支，而是把控制流摆到明面上，还能声明出来。开发者不再把逻辑悄悄埋进提示词或代码，而是写成能看、能改、能理清楚的执行计划。这样就形成了一种推理循环的控制流，LLM 在动态环境里可以借图结构去路由，去跑复杂的长耗时任务。

不少复杂任务，单体智能体应用已经干不动了。图系统催出了多智能体系统，由顶层的智能编排器来管任务流和依赖关系。往多智能体走，就需要成熟的协议来支撑智能体之间的异步通信，比如 A2A 和 ACP（后者最后并进了 A2A）。

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

在 LinkedIn，我们把现有的 LinkedIn 消息系统复用来做编排和智能体间通信，靠它处理长耗时任务——把任务拆成一条条消息，保证严格的“先进先出”（FIFO）投递，消息历史也能随时查。这套基础带来了：

• 并行能力：靠多个消息线程实现。
• 弹性：靠现有的持久重试和最终投递机制实现。
• 灵活的执行模式：智能体可以一次性给结果、同步流式输出，也可以跨多条消息异步流式输出。

基于图的工作流用 LangGraph 落地，带来了几项关键能力，让系统更结实，复杂度也更好管：

• 条件执行：可以依据中间结果对任务做路由、重新路由。
• 故障恢复方面，系统要能从出错状态中平稳抽身；中间数据不再只以文本形式存在，全流程都会保留结构化的状态；至于输出是否可信，则靠模式校验、业务规则或辅助模型来把关，而不是直接采信 LLM 给出的结果。

记忆能力同样不可缺。智能体需要从与用户的交互中不断学习，随着时间推移，让体验越来越个性化、能自适应、也真正好用。LinkedIn 的做法是基于分布式多智能体架构，把“认知记忆”单独做成一个智能体，供应用智能体接入使用。

这些尝试催生了 Hiring Assistant 的发布与后续迭代。据 LinkedIn 介绍，这是该公司首个面向招聘人员设计的 AI 智能体。招聘人员可以把耗时的工作交给它，比如寻找候选人、协助筛选申请人，自己则腾出精力处理更具策略性、更贴近人的核心事务。

走得越远越能体会到，想要真正出色的智能体体验，光有一个能力强的模型并不够。智能体得具备深厚的领域知识，这些知识建立在丰富的组织上下文之上，还要能持续迭代优化。说到底，这就需要记忆：从交互中学习，让招聘人员得到的体验日益个性化、能自适应、也真正实用。

图虽然比链向前走了一大步，能处理的任务复杂度明显扩展，但骨子里仍是人预先定义好工作流的自动化程序。工作流和状态空间越复杂，开发者的压力就越大——大量故障恢复逻辑、校验规则、边界异常处理都得手写。最终流程定义和评测框架往往变得脆弱、繁琐、难以维护。这种僵化也让基于图的方法应付不了那些没法清晰表达成确定性工作流的任务。

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

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

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

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

• 执行沙箱：一个受控的隔离环境，生成的代码可以在其中安全运行。
• 埋点与日志：捕获代码执行期间所有输出、错误和中间状态，方便后续排查问题。
• 验证 Harness：单元测试、断言或检查规则，自动验证生成代码的输出是否符合预期。
• 迭代优化循环：智能体识别到失败，系统地修改生成的代码，并自动重试执行，直到满足正确性要求。

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

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

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

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

• 把 LLM 输出当成不可信输入：大语言模型的输出具有概率性，在影响下游逻辑之前必须严格验证，未经核实绝不采信文本输出。流程继续往下走之前，先做 Schema 检查、业务与合规规则校验，或者交给辅助模型把关。
• 规划与执行要分开：让大模型提出计划，但计划要在严格受控的软件框架内执行。这种分离很关键，因为它能显著提升透明度
• 可观测性要跟上：一个复杂且高度非确定性的系统，若看不到内部行为，就无从调试。强大的可观测性必须捕获详细信息，包括智能体每一步的执行状态、执行轨迹和验证结果，同时对敏感信息做适当脱敏。
• 智能体系统天生是动态演进的，不是一成不变。要让它持续变好，就得建起反馈回路，把失败案例抓出来分析，让提示词、策略和程序记忆跟着迭代，同时在评估和仿真环境上持续投入。

图或者编码 Harness 会带来运维上的复杂度，不是每个问题都值得付这个代价。挑哪种抽象，说到底是在任务复杂度、可靠性要求、可解释性、延迟和成本之间做取舍。原则不复杂：能可靠解决问题的最简系统就是好系统。

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

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

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

模型在进步，成本在下降，可过度工程依然是最常见的翻车原因之一。更复杂的抽象，往往先推高算力和延迟、加重运维负担，而不是先改善业务结果。

真正的优势来自严谨地选抽象层：部署那个刚好满足可靠性、速度和成本要求的最简系统。工程能力强的组织，赢在把每一分成本换来的能力收益做到最大，而不是把架构复杂度堆到最高。

智能体系统跑得太快，开发者的角色也跟着变了。从“提示词设计师”到“系统架构师”，这个转型正在发生。早期链式 LLM 阶段，成败常取决于提示词写得漂不漂亮。系统演进到复杂的图和代码 Harness 之后，重心落到了扎实的软件工程上：设计执行流程、管理状态和依赖、搭好验证与恢复机制。

转变背后是更大的目标：从“尽力而为”转向“工程化可靠性”。早期系统把不可预测当成固有约束，就这么忍了。现代智能体 Harness 的要求更高——能确定的地方尽量确定，非确定性只在必要时用，而且要用得可控，故障模式和恢复路径都得写清楚。

走到这一步，AI 智能体已经从尖端边缘实验变成一流的生产级系统。新意不在组件本身，而在于它们怎么把概率模型嵌进确定性框架。

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

查看英文原文：

https://www.infoq.com/articles/agentic-ai-architecture-harness-evolution/