从提示到契约：面向可审计企业级LLM代理的约束工程

# 可审计的企业级LLM智能体：从提示到合约的"管控工程"

来源：https://arxiv.org/html/2607.08028

## 从提示到合约：面向可审计企业级LLM智能体的管控工程

Moonsoo Kim  
AI Leadership Research Center  
mskim@ceoai\.kr  
通讯作者。

###### 摘要

企业级大语言模型（LLM）应用往往起步于原型，其行为由提示（prompts）和检索上下文承载。产品化过程引入了对源边界（source boundaries）、实体路由（entity routing）、答案合约（answer contracts）和可复现轨迹（reproducible traces）的要求。我们提出一种"管控工程"（harness engineering）方法，将这一模式重构为可追踪、可审计的LLM智能体架构：确定性行为迁移至代码、清单（manifests）、模式（schemas）和验证工件（validation artifacts）中，围绕一个可替换的组合边界（replaceable composition boundary）组织，而运行时答案的权威来源仍由基于源的声明（source-backed claims）提供。我们在一个包含五个韩国企业集团（25家上市公司）的公共数据切片上实现了该方案，并评估了三个研究问题：（1）在固定验证场景集合下，该管控层（harness）维持了源扎根（source-grounding）、实体路由、轨迹、输出卫生（output-hygiene）和推荐语言合约；故障注入对照实验表明，验证器能够正确标记被故意破坏的合约。（2）管控层强制执行的检查在模型替换下依然有效：在三个托管模型上，所有270次组合边界运行均通过检查；失败仅发生在模型组合侧，且被捕获并记录。（3）代码所有（code-owned）的保证是承载属性的，无法仅通过提示复现：固定模型不变，仅变更强制层，仅靠提示指令会让推荐语言和内部轨迹泄露违规到达读者，而管控层完全阻止了这些。附加的外部护栏（bolt-on external guardrail）也能阻止此类违规，但过度拒绝，将效用降低至88/120，而管控层保持了完整效用（120/120）；在该消融实验中，只有代码所有强制层同时保证了安全性和效用。最终成果是一个可复用的工程模式，用于将探索性原型转化为带有版本化源、控制和验证工件的可审计应用。

## 1 引言

企业级大语言模型（LLM）应用通常以演示形式进行初步探索：包含系统提示（system prompt）、一组检索文档，以及展示预期交互的用户界面。我们将原型称为"提示主导型"（prompt-dominant）应用——当重要的产品行为主要编码为自然语言指令或广泛的检索上下文，而代码、数据合约和验证工件仍不完善时。提示主导的开发方式在探索阶段很有用，与"氛围编码"（vibe coding）相关，这是一种由Karpathy推广的、基于对话式LLM辅助的软件开发工作流[1 (https://arxiv.org/html/2607.08028#bib.bib1),2 (https://arxiv.org/html/2607.08028#bib.bib2)]。这类提示能够良好地展示行为，但不足以保证行为。产品化引入了仅靠提示无法强制实现的需求：每个可见陈述应可追溯到限定源、路由到正确实体、在断言内容上受约束、在相同假设下可重新生成，并通过显式的版本化工件进行审计。这些关注点与人工智能（AI）系统的幻觉和软件工程控制方面的先前工作相联系[3 (https://arxiv.org/html/2607.08028#bib.bib3),4 (https://arxiv.org/html/2607.08028#bib.bib4),5 (https://arxiv.org/html/2607.08028#bib.bib5)]。本研究通过重建一个基于LLM的投资简报智能体来考察这一过渡。该动机原型是在CEO AI[6 (https://arxiv.org/html/2607.08028#bib.bib6)]主办的为期十周的AI领导力项目中开发的；作者在此项目背景下，以AI领导力研究中心的名义报告这项工作。在项目期间，作者为高管和客户场景构建并演示了十多个探索性AI产品原型，使用Replit托管的演示向参与者分享交互模式[7 (https://arxiv.org/html/2607.08028#bib.bib7)]。投资简报原型提供了这些模式，包括移动优先的简报卡片、源链接和后续问题。该原型作为一个动机背景，用于重建一个具有不同源、轨迹和验证结构的系统。我们采用"管控工程"（harness engineering）——一种将LLM智能体包裹在代码所有的控制层中的新兴实践[8 (https://arxiv.org/html/2607.08028#bib.bib8),9 (https://arxiv.org/html/2607.08028#bib.bib9),10 (https://arxiv.org/html/2607.08028#bib.bib10)]——并将其发展为一种可测量的、基于合约的方法，将产品行为从提示中迁移到显式的版本化合约中[11 (https://arxiv.org/html/2607.08028#bib.bib11),12 (https://arxiv.org/html/2607.08028#bib.bib12)]。在软件工程中，测试筒（test harness）指用于在尚未准备好较高级代码的情况下，预先执行较低层代码的脚手架代码[13 (https://arxiv.org/html/2607.08028#bib.bib13)]。我们将测试筒的思路适配到企业级LLM智能体：管控层就是那个控制层，由代码而非提示所有，负责源门控（source gates）、路由规则、声明资格（claim eligibility）、答案合约、轨迹生成和验证。在重建架构中，清单定义了哪些源可以被使用；基于源的声明定义了哪些语句可以进入运行时上下文；路由元数据将问题绑定到实体；答案合约定义了可见的答案；轨迹记录了答案是如何组装而成的。维护的wiki页面提供简洁的上下文，而源清单和基于源的声明保持权威性。本文做出四项贡献：(i) 一种将提示主导的企业级LLM原型重建为可追踪LLM智能体架构的管控工程方法；(ii) 一条源到声明的知识流水线，将原始文档、证据记录、运行时可用声明、维护的wiki上下文和面向读者的答案分离开来；(iii) 一个可替换的组合边界（replaceable composition boundary），将确定性的管控控制与LLM措辞分开；(iv) 一个系统级验证设计，检查源扎根、实体路由、轨迹完整性、输出卫生、运行时接口行为、延迟以及实时LLM组合边界行为。我们在一个受限的公共数据切片上实例化了该方法，包含五个韩国企业集团、25家上市公司和113个基于源的运行时声明。通过三个研究问题评估了此重建，涵盖合约保持、模型替换和承载强制：

1.  RQ1. 重建的管控层在固定验证集上是否保持了源扎根、实体路由、轨迹、输出卫生和推荐语言合约？
2.  RQ2. 当组合边界的语言模型被替换时，这些保证是否仍然成立——即，这些保证是否跨不同模型成立，而非仅依赖于某一模型的行为？
3.  RQ3. 代码所有的保证是否是承载属性的——由管控层强制实施，而非仅凭提示指令就能复现？

我们通过固定场景和故障注入结果处理RQ1，通过跨三个托管模型的实时LLM组合边界检查处理RQ2，通过一个禁止代码所有验证与回退（validation-and-fallback）门的强制层消融实验处理RQ3，并将其与附加的外部护栏进行对比。与此框架一致，本研究评估的是系统级可验证性，而非投资决策质量；后者是一个独立的领域价值问题，不在本研究的范围之内。

## 2 相关工作

本节回顾将LLM智能体原型转变为可追踪企业系统所需的研究和工程实践。核心问题是：答案在呈现给用户之前，如何被扎根、组装、约束和验证。

#### RAG与可追溯性。
检索增强生成（RAG）将语言模型与外部文档相结合，以改进事实基础和可更新性[14 (https://arxiv.org/html/2607.08028#bib.bib14),15 (https://arxiv.org/html/2607.08028#bib.bib15)]。后续研究表明，检索还必须具有选择性和可检查性：自反检索方法询问是否需要检索以及生成是否得到支持[16 (https://arxiv.org/html/2607.08028#bib.bib16)]，而事实性和归因方法则检查生成内容与其证据之间的一致性——将答案分解为原子事实[17 (https://arxiv.org/html/2607.08028#bib.bib17)]，或为每个生成的语句附上源引用[18 (https://arxiv.org/html/2607.08028#bib.bib18)]。然而，对已部署的生成式搜索引擎的评估表明，流畅的答案经常引用实际上并不支持它们的来源[19 (https://arxiv.org/html/2607.08028#bib.bib19)]，这正是源到声明层必须防止的产品级失败。智能体增强变体进一步编排检索过程，例如通过个性化检索内容[20 (https://arxiv.org/html/2607.08028#bib.bib20)]，但编排本身并不能使来源变得权威。检索选择性和事实可检查性直接关系到企业领域，其中披露文件、投资者关系（IR）材料、新闻和监管文件会随时间变化。检索提供事实上下文，而可追溯性额外要求源出处、实体范围以及声明级支持——即可归属于已标识来源的属性[21 (https://arxiv.org/html/2607.08028#bib.bib21)]。检索到的段落可能过时、不相关或混合了不同实体，流畅的生成仍可能产生幻觉[3 (https://arxiv.org/html/2607.08028#bib.bib3)]。在产品层面解决这些限制，需要将答案扎根于一个结构化的源到声明层，而不是仅仅依赖检索。我们的方法将RAG视为代码所有管控层内部的一个组件，围绕该组件进行构建。

#### LLM智能体与验证。
经典的智能体研究强调自主性、交互和显式的系统架构[22 (https://arxiv.org/html/2607.08028#bib.bib22),23 (https://arxiv.org/html/2607.08028#bib.bib23)]。LLM智能体通过工具使用、规划、搜索和中间执行轨迹扩展了这一传统[24 (https://arxiv.org/html/2607.08028#bib.bib24),25 (https://arxiv.org/html/2607.08028#bib.bib25),26 (https://arxiv.org/html/2607.08028#bib.bib26),27 (https://arxiv.org/html/2607.08028#bib.bib27)]。工具使用基准进一步表明，应用程序编程接口（API）的选择和执行既是工程问题，也是提示问题[28 (https://arxiv.org/html/2607.08028#bib.bib28)]。近期的应用工作还报告了多平台智能体部署和可编程智能体运行时架构[29 (https://arxiv.org/html/2607.08028#bib.bib29),30 (https://arxiv.org/html/2607.08028#bib.bib30)]。本文的重点从多平台部署转向企业级加固，其核心要求是可审计性：每个答案都必须记录哪些源、工具、声明和回退路径影响了最终输出。对多智能体LLM系统失败原因的实证分析将任务验证确定为一个反复出现的失败类别[31 (https://arxiv.org/html/2607.08028#bib.bib31)]，这促使将验证作为一个显式的、强制执行的合约而非涌现的模型行为。

#### 智能体编排框架。
除了研究基准，近期的编排框架使智能体工程更加具体。AutoGen支持多智能体对话和协调[32 (https://arxiv.org/html/2607.08028#bib.bib32)]；LangChain Agents提供预构建的工具调用循环，LangGraph为有状态智能体提供基于图的运行时[33 (https://arxiv.org/html/2607.08028#bib.bib33),34 (https://arxiv.org/html/2607.08028#bib.bib34)]；CrewAI组织基于角色的智能体、团队和流程[35 (https://arxiv.org/html/2607.08028#bib.bib35)]。我们提出的控制层与这些框架互补：编排框架处理智能体的组合和执行方式，而本研究涉及的模式则关注每个生成的答案是否扎根于源清单、基于源的声明、输出合约和验证轨迹。这个扎根与合约层是这些框架留给应用来处理的：它们协调智能体的运行方式，但本身并不决定哪些基于源的声明可以进入答案，也不对答案强制执行验证合约。由于合约定义在组合边界上，而非任何单一运行时内部，因此它们旨在保持与底层编排运行时的无关性——无论是AutoGen、LangChain、LangGraph、CrewAI还是自定义的智能体循环。

#### 提示工程与原型设计。
提示工程之所以重要，是因为LLM能够通过自然语言指令和上下文中的示例来执行新任务[36 (https://arxiv.org/html/2607.08028#bib.bib36)]。此后，提示工程被综合为系统的综述，分类整理了通过提示设计塑造模型输出的技术[37 (https://arxiv.org/html/2607.08028#bib.bib37),38 (https://arxiv.org/html/2607.08028#bib.bib38)]。诸如思维链提示等技术进一步表明，改变提示可以显著改变推理行为[39 (https://arxiv.org/html/2607.08028#bib.bib39)]。"氛围编码"将提示设计从孤立的任务指令扩展为一种迭代开发工作流，软件行为通过与AI工具的自然语言对话共同创建[1 (https://arxiv.org/html/2607.08028#bib.bib1),2 (https://arxiv.org/html/2607.08028#bib.bib2),40 (https://arxiv.org/html/2607.08028#bib.bib40)]。这类工作流自然会产生提示主导型原型，其中源策略、实体路由、答案结构、数据新鲜度规则和用户界面行为在快速迭代过程中嵌入到提示中。提示和氛围编码对于早期探索很有价值，也解释了原型系统为何能够快速构建。然而，由于这些职责是隐式的且相互纠缠，审计、重放和迁移需要将它们从提示中迁移到显式的工件中。

#### 从可编程流水线到管控工程。
多个框架主张LLM应用应该使用显式的软件抽象进行编程、测试和优化，而不是隐藏在提示内部。在调用层面，Language Model Query Language (LMQL) 通过声明式约束限制模型解码[12 (https://arxiv.org/html/2607.08028#bib.bib12)]，Instructor 通过自动验证重试强制执行类型化输出模式[41 (https://arxiv.org/html/2607.08028#bib.bib41)]，Guidance 在单个模型会话中交错控制流与受限生成[42 (https://arxiv.org/html/2607.08028#bib.bib42)]。在流水线层面，Demonstrate-Search-Predict 及其后继 DSPy 将多步流水线表示为声明式程序，可作为软件进行测试和优化[43 (https://arxiv.org/html/2607.08028#bib.bib43),11 (https://arxiv.org/html/2607.08028#bib.bib11),44 (https://arxiv.org/html/2607.08028#bib.bib44)]。在运行时层面，NeMo Guardrails 定义独立于底层模型的行为轨道[8 (https://arxiv.org/html/2607.08028#bib.bib8)]，Llama Guard 过滤不安全的输入和输出[45 (https://arxiv.org/html/2607.08028#bib.bib45)]，更广泛的文献将此类护栏视为一个独立的约束模型行为的设计层[9 (https://arx