**标题：智能体架构演进：从链式提示到代码化 Harness，生产级可靠性取代“尽力而为”**

一句话结论

智能体架构正从链式、图范式向代码化 Harness 演进，通过引入确定性验证与沙箱执行，实现生产级可靠性并大幅降低运维复杂性。

关键要点

• 链式范式依赖线性提示词串联，构建快但上游错误级联传播，缺乏系统性错误识别与自动修复机制，仅适合低风险线性任务。
• 图范式引入显式控制流、条件分支与多智能体协议（如 A2A），支持长耗时任务编排，但需手动编写大量故障恢复与校验逻辑，维护成本高昂。
• 代码化 Harness 以生成、执行和迭代优化确定性代码为核心，通过沙箱、埋点、验证与反馈循环实现可验证输出，显著提升可审计性与可复现性。
• 构建健壮智能体需遵循四项最佳实践：将 LLM 输出视为不可信输入、规划与执行解耦、强化可观测性、建立持续改进反馈回路。
• 架构选型应基于任务复杂度、可靠性要求、延迟与成本权衡，原则是“使用能可靠解决问题的最简单系统”，避免过度工程化。

背景与事实

在基于大语言模型构建智能体的早期阶段，开发者主要采用链式范式，即通过粘合代码将一系列提示词串联，形成线性工作流。以 LinkedIn 早期基于 LangChain 框架构建的生成式 AI 智能体为例，其采用固定三步流程：路由步骤判断查询范围并分配专家，检索步骤调用必应网页搜索或内部 API 收集信息以支持 RAG，生成步骤则过滤综合数据形成最终答案。这种方案虽能快速上线，但极度脆弱，上游任一错误都会级联传播，且系统缺乏内置机制来识别或修复错误，整体呈现“尽力而为”特征，需依赖大量评估与提示词优化迭代才能逼近生产质量。

随着应用场景复杂化，图范式成为主流。基于 LangGraph 的图系统将任务抽象为节点，通过边控制流程，实现条件执行、重试回退、结构化状态管理与显式验证。LinkedIn 复用现有消息系统处理长耗时任务，将任务拆分为消息序列，保障 FIFO 投递与历史查找，支持并行、弹性与同步/异步流式输出。图系统还催生多智能体架构，通过 A2A 协议实现异步通信，并引入“人在回路”机制在关键决策点向人类寻求澄清。LinkedIn 基于此发布了 Hiring Assistant，协助招聘人员筛选候选人，但开发者仍需手动编写大量故障恢复与校验规则，导致流程定义繁琐、易碎，且不适合无法表达为确定性工作流的任务。

最新突破是代码化 Harness 范式，将代码而非提示词作为推理主要媒介。该架构在沙箱环境中生成、执行并优化代码，打破需预先设计复杂工作流的局限。LinkedIn 构建了内部工具，让非技术用户以自然语言提问，智能体将查询转换为声明式 SQL 与 Python 代码组合，在样本数据上执行并依据隐私、合规与可见性约束验证输出，循环迭代直至满足正确性要求。该工具在现有权限框架内运行，叠加自动化合规审查，显著缩短了上线时间并提升了系统可审计性与可复现性。

影响分析

对中文开发者与从业者而言，该演进意味着技术栈与职业定位的双重转变。在工程实践层面，仅掌握提示词工程已不足以支撑生产级智能体开发，需转向系统架构师角色，具备沙箱设计、状态管理、可观测性构建与验证框架搭建等软件工程能力。例如，采用代码化 Harness 的开发者必须建立执行隔离、日志埋点、断言验证与迭代反馈四大核心组件，这要求团队具备传统软件测试与基础设施运维的复合能力。在成本与效率层面，架构选型直接决定资源投入：简单客服、文档总结等线性任务应坚持链式方案以最小化模型调用与状态管理开销；而金融分析、软件工程等高精度场景则需接受代码化 Harness 带来的更高计算与延迟成本，以换取确定性输出。这一趋势将倒逼企业重新评估 AI 项目的 ROI，避免盲目引入复杂图或代码框架导致运维成本失控。

适用边界

上述架构选型结论不适用于以下场景：任务输出无法通过编译、测试、断言或仿真等确定性方式验证，例如创意写作、开放式策略咨询或高度主观的情感交互；组织缺乏构建沙箱、日志与验证基础设施的工程能力或合规团队；对实时性要求极高且可接受概率性偏差的轻量级交互场景。在这些条件下，代码化 Harness 的迭代循环与验证开销将产生负面影响，链式或简化图方案仍是更优选择。

孤本观察

本文揭示的核心判断是：智能体架构演进的实质并非单纯追求技术复杂度，而是将概率模型约束进确定性软件框架的可靠性工程过程。这一判断基于 LinkedIn 从“尽力而为”的链式系统到可审计、可复现的代码化 Harness 的完整实践路径，其价值不在于组件创新，而在于抽象层选择对业务成果的精准匹配。

来源：InfoQ 中文 AI