简介：本文深入解析“代理工程”的核心原理，探讨如何通过工程化手段而非单纯提示词调优，为不稳定的大模型构建确定性执行环境。文章将拆解“护栏”机制的系统组成、工作流程与关键技术模块，说明其如何锚定模型输出、隔离敏感操作、保障复杂任务稳定完成，并分析该机制的技术优势、适用边界与常见实践误区，帮助开发者构建可信赖的智能体应用。
代理工程（Harness Engineering）是一套系统化的软件工程方法论，其核心目标是在大语言模型（LLM）驱动的智能体应用外部，构建一层稳定的、开发者可控的执行框架。该框架通过在模型与业务系统之间插入控制层，将模型的自由文本输出约束为结构化、可校验、可回滚的操作序列。这并非对模型能力的增强，而是对模型不确定性的系统性抑制。
其核心原理可概括为：通过确定性工程手段封装非确定性模型行为。大语言模型本质上是概率系统，其输出受训练数据、采样参数、上下文窗口等多重因素影响。代理工程不试图消除这种概率性，而是承认其存在，并通过外部结构化机制将其限制在安全的边界内。这种边界由代码、配置、校验规则和状态机共同构成，形成所谓的“护栏”。
在早期智能体应用中，开发者的直觉是将所有逻辑都写入提示词，期望模型能够遵循复杂指令完成多步任务。这种做法的核心假设是：模型能力足够强，且提示词足够精确时，输出必然可信。然而实际工程实践中，该假设面临三重挑战：
第一，提示词的脆弱性。模型对措辞极其敏感，同一意图的不同表述可能导致截然不同的输出分布。修改一个标点或调整指令顺序，可能影响下游解析逻辑的稳定性。
第二，模型版本漂移。基础模型迭代时，即使提示词不变，输出的概率分布也会变化。这导致依赖精细提示词的智能体应用不得不频繁回归测试和调参。
第三，幻觉累积。在多步任务中，模型每一步都可能引入微小偏差。如果没有外部校验机制，这些偏差会在后续步骤中被放大，最终导致任务链崩溃。
提示词调优的核心问题是：它试图在概率空间内寻找一个“足够好”的局部最优解，但无法改变模型输出的本质——非确定性。当任务复杂度超过阈值后，调优的边际成本急剧上升，收益趋于零。代理工程正是对这一问题根源的回应：不再执着于让模型“不出错”，而是通过工程手段让模型“即使出错也不影响结果”。
理解代理工程，需要建立三个基础概念。
护栏（Guardrails） 并非物理意义上的限制，而是一组运行时的检查、约束与回退机制。它定义了什么操作允许自动执行、什么操作需要人为审批、什么情况必须终止流程。护栏的粒度可以从字段级（如输出必须符合JSON Schema）到任务级（如不得超过三次自动重试）。
锚定（Anchoring） 指将模型的自由输出绑定到开发者预先定义的结构上。其本质是用外部结构化数据（如枚举值、正则表达式、受控SQL语句）替代模型想象空间中的自由文本。锚定越强，模型输出偏离轨道的可能性越低。
可控性（Controllability） 是衡量系统在异常情境下能否被安全处置的指标。可控性好的系统具备三个特征：可观测性（所有状态变化可追踪）、可干预性（人为可中断或改道）、可恢复性（失败后能从检查点重启）。
这三者构成了代理工程与单纯提示词调优的根本差异：提示词调优试图提高正确输出的概率，而代理工程则保障即使概率未提升，错误输出也不会造成实质危害。
一个完整的代理工程框架通常由六个核心模块组成，它们通常以中间件或SDK的形式嵌入智能体应用：
1. 输入净化层
负责将用户输入或上游系统数据在进入模型之前进行规范化处理。包括去掉可能引发注入攻击的指令、裁剪超长上下文、标注敏感字段。其核心逻辑是减少模型输入空间的不可预测性。
2. 规划器（Planner）
将复杂任务分解为子步骤序列。这一层通常由一个小型模型或规则引擎驱动。规划器的输出并非最终动作，而是待执行的任务清单，清单中的每一步都需要经过护栏验证。
3. 动作执行器（Actor）
根据规划器的指令调用外部工具或API。它不直接执行模型生成的原始字符串，而是将字符串映射到白名单内的预定义操作。例如，模型输出“删除数据库某表”，执行器会先检查该表的保护策略，再决定是否放行。
4. 校验器（Validator）
对模型输出或执行结果进行结构化校验，包括语法校验、业务规则校验和状态一致性校验。当校验失败时，触发修复策略或回退机制。
5. 状态存储器
维护任务执行的完整状态快照，包括当前步骤、中间结果、已消耗的资源和运行上下文。这是实现可恢复性和断点续跑的基础。
6. 审计日志器
记录所有输入、输出、校验结果、异常事件和人为干预操作。该日志不仅用于追溯，还能通过统计频率来分析哪些步骤最容易触发护栏，继而反向优化规划器。
以自动化数据处理任务为例，说明代理工程的完整运行流程：
第一步：输入接收与解析
系统接收原始请求（如“汇总本周销售数据并生成报告”）。输入净化层检查请求内容，过滤掉冗余信息与潜在注入指令，构建结构化任务对象。
第二步：任务规划
规划器将任务分解为子步骤序列：连接数据库、提取数据、计算汇总值、格式化报表结构。这一步骤的输出是一份带有依赖关系的任务图。
第三步：护栏预检
每个子步骤执行前，需通过权限检查（当前身份是否有权访问该数据源）、配额检查（是否在限定资源额度内）、依赖检查（前置数据是否就绪）。
第四步：模型生成与动作映射
对于需要模型判断的环节（如决定报表的图表类型），模型在受限选项集合内生成候选结果。执行器在候选集合中选取一个，并映射到具体API调用参数。
第五步：执行与验证
API调用后，校验器检查返回结果的结构完整性和内容合规性。若结果异常，进入重试策略：先重新生成候选，其次调整操作参数，最后升级到人工审批。
第六步：状态更新与持久化
每步完成后，状态存储器更新任务快照。若后续过程发生故障，可从最近的有效检查点恢复，无需从头重跑。
第七步：结果交付与审计
最终结果经格式转换后交付给用户。审计日志记录全链路数据，供后续分析。
模型生成文本后，通过受控解码或后处理强制将其转换为符合预设Schema的JSON对象。该机制确保后续代码解析时的类型安全，彻底消除因格式漂移引发的解析错误。其副作用是可能降低输出的自然度，但工程收益远大于代价。
涉及数据删除、权限变更、资金转移等敏感操作时，系统采用“双通道验证”模式：模型生成的指令仅作为草案，必须经过独立校验引擎审核或人工签字才能执行。校验引擎根据操作类型、影响范围、历史风险等级执行差异化策略。这种设计使风险控制在应用层，而非依赖模型自身判断。
每个任务实例都是一个有限状态机实例。状态迁移路径由配置文件预先定义，模型无法创造新的状态。例如，任务只能从“待规划”迁移到“执行中”，再到“已完成”或“已终止”，不存在“已取消”与“已完成”的歧义叠加。状态机有效防止了并发或异常情况下任务流的一致性问题。
针对外部API调用失败，采用指数退避重试。同时监控失败率指标，当连续失败次数达到阈值时触发熔断——暂停向该API发送新请求，并将任务标记为待人工检查。该机制防止了模型在错误路径上反复消耗资源。
与业务强相关的规则（如“金额不能为负”“用户ID必须存在”）不依赖模型判断，直接在框架代码中实现。这被称为“最后一公里的确定性”。模型只负责生成意图，不负责推导结果是否符合物理世界规则。
代理工程的核心优势体现在四个方面：可靠性（模型输出被限制在安全区间内）、可维护性（业务逻辑在代码层，不依赖提示词版本管理）、可审计性（所有操作均有记录和校验点）、成本可控（可使用较小规模的模型完成复杂任务，因为外部框架补齐了逻辑性）。
但其存在明确的技术边界：
误区一：“用了护栏就不再需要提示词优化”
护栏解决了确定性约束问题，但提示词依然影响任务规划的合理性。两者互为补充：提示词负责语义理解，护栏负责动作安全。
误区二：“护栏等于输入过滤”
输入净化只是护栏的第一步。真正的护栏覆盖全链路，包括输出校验、状态转换限制和终止策略，是体系化设计。
误区三：“只要检查输出格式就等于有护栏”
格式合规是基础设施，业务规则的语义校验更重要。仅检查JSON格式但接受了一个不合逻辑的转账指令，仍然会产生真实损失。
误区四：“护栏是静止的规则库”
有效护栏是持续演进的系统，需要通过审计日志不断分析禁住的行为模式和漏网的异常事件，从而迭代更新规则。
代理工程揭示了一条清晰的工程路线：在模型能力未完全解决可靠性问题之前，通过外在结构来保障系统行为可控。它的底层机制并非依赖模型自我反思，而是依赖代码的确定性执行与规则的有界校验。从架构视角看，它将智能体应用重新定义为“模型承担语义引擎、工程框架承担控制逻辑”的双组件系统。对开发者而言，掌握代理工程的意义在于建立一种思维转变：不再试图通过调优一个概率模型来获取确定性，而是接受不确定性，并设计一套机制来让其变得无害。这将是构建可信赖、可落地到生产环境的智能体应用的关键基础。