26年5月来自CMU, Yale大学, JHU, 东北大学（NEU）, Tulane大学, 阿拉巴马大学（UAB）, 俄亥俄州立（OSU）, Virginia Tech 和Amazon公司的论文"Agent Harness Engineering: A Survey"。
大语言模型（LLM）智体在生产环境中的快速部署揭示一个反复出现的规律：任务执行的可靠性与其说取决于底层的语言模型本身，不如说更多地取决于包裹该模型的"基础设施层"------即智体Harness（Agent Harness）。本综述基于实践经验，对智体Harness工程进行系统性的梳理，并围绕三个核心论点展开。首先，智体harness是一个独立的系统层，其工程质量在很大程度上决定实际应用中的系统可靠性；通过三个阶段的工程演进（从"提示工程"到"上下文管理"再到"harness工程"）来阐述这一观点，并在此基础上进行跨层级的综合分析，涵盖"成本-质量-速度"三难困境、"能力与控制"的权衡取舍，以及"harness耦合"等关键问题；此外，还提出一系列开放性研究议题，旨在填补当前研究领域的空白并解决生产环境中的痛点。其次，提出 ETCLOVG 这一七层分类体系（分别代表：执行环境、工具接口、上下文管理、生命周期/编排、可观测性、验证、治理）；该体系在既有的六组件框架基础上进行扩展，将"可观测性"和"治理"提升为独立的架构考量要素。第三，将 170 多个开源项目映射至上述分类体系中，旨在揭示当前生态系统的发展模式、覆盖范围的空白点以及正在涌现的设计原则；与此同时，还提炼一系列源自 OpenAI、Anthropic 和 LangChain 等机构生产部署实践的工程原则，旨在弥合从业者经验知识与学术研究术语体系之间的鸿沟。
如图4所示智体Harness工程分类体系的详细内容：
。。。继续。。。
可观测性与运维（O）是 ETCLOVG 体系结构的第五层，主要探讨如何在生产环境中对智体（Agent）的行为进行监控、调试并确保其可靠运行。可观测性理应作为独立议题进行专门探讨，而不应仅仅归属于"生命周期钩子"的范畴；究其原因，可观测性领域已然衍生出一个涵盖各类平台、技术规范及工程实践的独立生态系统。
1 追踪与监控平台
智体可观测性的基石在于"结构化追踪数据采集"：即把每一次大语言模型（LLM）调用、工具调用、检索步骤以及上下文组装操作，都记录为一棵由若干"跨度"（Span）构成的树状结构，以便后续进行检查、筛选及回放。
Langfuse、Opik、Arize Phoenix 和 MLflow 等平台均提供交互式的追踪树视图，并辅以延迟火焰图、Token 用量明细、成本归因仪表板以及提示词版本管理等功能（Langfuse 2026; Comet ML 2026; Arize AI 2026b; MLflow 2026）。这些平台通常通过轻量级的 SDK 封装层（例如 @traceable 装饰器）来摄取追踪数据；这些封装层能够以极小的代码改动量，对智体的函数调用过程进行埋点（Instrumentation）。
在这些平台的基础设施层面上，OpenTelemetry（OTel）已然确立其作为事实上的埋点标准地位。OTel 社区针对生成式 AI 领域发布了一套语义约定（Semantic Conventions），明确定义了用于描述模型名称、温度参数、Token 计数及延迟时间等关键信息的 Span 属性（OpenTelemetry 2026）。目前已有两个开源项目致力于将这些约定落地实践：OpenLLMetry 针对各类 LLM 服务提供商（如 OpenAI、Anthropic、Cohere）及向量数据库（如 Pinecone、Chroma、Weaviate）提供了自动埋点库，能够自动生成符合标准的 OTel Span 和指标数据（Traceloop 2026）；而由 Arize AI 维护的 OpenInference 项目，则提供了一套互补性的技术规范，其语义约定同样与 OTel 保持一致，并提供了相应的自动埋点工具，旨在作为 Arize Phoenix 平台的配套辅助工具使用（Arize AI 2026a）。通过基于 OTel 进行构建，这些库使得智体（Agent）的追踪数据能够流入团队已用于传统微服务监控的同一套可观测性后端系统（如 Prometheus、Jaeger、Grafana 和 Datadog），从而降低了采用特定于智体的专用工具所带来的运维开销。
在更深层的插桩（Instrumentation）层面，学术界已探索出一些超越应用层装饰器（Decorators）的技术。AgentSight（Zheng，2025年）利用 eBPF 在应用进程外部对智体进行监控：它在 SSL 边界处拦截经过 TLS 加密的 LLM 流量以捕获意图，并通过监控内核事件（如进程创建、文件 I/O 和网络调用）来捕获具体动作。一个实时关联引擎负责将 LLM 的响应与其所触发的系统行为进行关联；此外，一个辅助性的"观察者"LLM 会执行语义分析，以识别潜在风险。这种方法不依赖于特定的框架，无需修改任何代码，且产生的 CPU 开销不足 3%。作者指出，相比应用层工具，这种方法具有结构上的优势：系统级监控无法被受损或配置错误的智体所绕过，这使得该技术对于安全性至关重要的部署场景尤为适用。AgentTrace（AlSayyad，2026年）提出了一种互补的、基于模式（Schema）的日志记录框架，该框架在三个不同的"层面"上捕获结构化日志：认知推理步骤、规划与反思；操作层面的工具调用与 API 交互；以及上下文环境状态与用户输入。这些层面的数据被整合在一个统一的"信封"（Envelope）结构中，并与 OTel 集成以便于数据导出。其中，"认知层面"对于"智体工程"（Agent Engineering）领域尤为重要，因为它捕获了显式的推理过程产物、行动规划、反思记录以及自我纠正过程。这些记录为调试那些因推理错误而非系统故障引发的系统失效问题，提供了宝贵的原始素材。
2 智体专用运维平台
通用的追踪平台往往将其抽象模型的核心聚焦于 LLM 调用、工具调用以及检索步骤，并将这些视为 Span 级别的独立事件。而智体专用平台则在此基础上增加了一个抽象层，专门用于捕获智体层面的关键要素：包括多步会话追踪、智体身份与角色管理、工具选择策略，以及跨会话的状态传递。AgentOps SDK 引入了一种分层式的 Span 模型（AgentOps AI，2026年），该模型围绕智体的生命周期来组织会话、智体实体、具体操作/任务、工作流、工具调用以及 LLM 调用，而非将它们视为彼此孤立的 API 调用。 RagaAI Catalyst 专注于 RAG（检索增强生成）和多智能体工作负载，通过提供质量与安全仪表板，揭示检索层级及智体层级的异常情况（RagaAI, 2026）。Laminar 则提供一套"开源优先"的智体可观测性平台，集成了追踪、评估及提示词管理功能（Laminar AI, 2026）。
学术界已开始着手将这些关切正式化。研究人员 Moshkovich 与 Zeltyn（2025）提出了一套六阶段的 AgentOps（智体运维）自动化流程：观测、指标收集、异常检测、根因分析、修复建议，以及自动化修复。他们进一步将涉众空间细分为四种角色：开发者、测试人员、SRE（站点可靠性工程师）和业务用户，每一类角色都在管道（pipeline）生命周期的不同阶段与之进行交互。他们的配套实证研究（Moshkovich，2025）引入了"任务流发现"这一可观测性原语，并通过用户研究表明，79%的从业者认为非确定性执行流是智体系统（agentic systems）面临的最重大挑战。
自然语言-智体驾驭（NLAH）框架（Pan，2026）及其配套的开源实现，采取了一种互补的策略：将"驾驭"本身视为一类"第一等公民"式的研究对象。通过系统的消融实验，作者量化各个线束模块对下游智体性能的具体贡献。这些模块包括工具注册表、权限系统、钩子（hooks）、技能集以及上下文折叠机制。这对可观测性领域的启示在于：线束不仅仅是监控的对象，更是实施干预的源头------每一个被消融（即被移除以测试其影响）的模块，都相当于一个可供可观测性管道识别并调节的"旋钮"。
"认知可观测性"将智体层面的监控范畴进一步拓展，不仅探究智体"做了什么"，更深入追问其"为何而做"。Watson Rombaut（2025）正式提出了这一概念，并部署了一个"代理智体"（surrogate agent）：该智体在复现主智体输出结果的同时，利用"提示归因"（prompt attribution）技术生成逐步骤的推理轨迹。在针对 AutoCodeRover 和 OpenHands 智体系统进行的 MMLU 和 SWE-bench-lite 基准测试中，Watson 证明所恢复的推理轨迹无论对于人工调试还是自动化修正都极具价值，并带来了任务成功率方面可量化的提升。AgentLens（Lu ，2024）通过一套包含三个面板的可视化分析系统，构建了一个完整的可视化闭环：其中的"概览视图"（Outline View）用于展示智体的运行轨迹；"智体视图"（Agent View）用于呈现包含因果关联弧线的事件堆栈；而"监控视图"（Monitor View）则用于实现环境状态的同步回放。该系统能够将原始的执行日志转化为具有层级结构的智体行为叙事。一项包含14名参与者的用户研究结果显示，在处理复杂的分析任务时，该系统相较于仅具备回放功能的基准系统，展现出了显著的性能提升。此外，还有一些更为专用的可视化工具（例如 claude-code-reverse），能够对特定代码生成智体的交互链进行"逆向工程"分析；这些工具不仅本身具有研究价值，更可作为理解驾驭层面智体行为机制的重要研究辅助资料（Yu，2026）。
3 成本追踪与优化
大语言模型（LLM）的推理服务通常按 Token数量计费。由于 Agent 驾驭（Agent Harnesses）可能导致单个面向用户的任务触发数十次 LLM 调用------且每次调用都涉及独立的提示词组装、工具结果注入及响应生成过程------这极大地放大了潜在的成本风险。因此，对可观测性的需求主要体现在两个方面：追踪（即明确 Token 消耗的具体去向）与优化（即在达成相同任务结果的前提下，尽可能减少 Token 的消耗）。
在成本追踪方面，TensorZero 提供一套统一的 LLMOps 堆栈，将网关、可观测性、实验管理及优化功能整合为单一服务，从而实现了对每一次 LLM 调用及每一个任务的精细化成本归因（TensorZero, 2026）。相比之下，Helicone 采取一种极简主义的方案：作为一个"即插即用"的代理层（Proxy），它无需修改任何现有代码即可为系统增加成本与延迟监控功能。这一特性使其特别适用于那些希望获得成本透明度，却不愿投入资源去部署整套复杂可观测性平台的团队（Helicone, 2026）。
在成本优化方面，FrugalGPT（Chen et al., 2023）奠定了理论基础，并提出了三种主要的成本削减策略：提示词自适应（Prompt Adaptation）、LLM 近似推理（LLM Approximation）以及 LLM 级联调用（LLM Cascading）。该研究表明，通过构建自适应的级联调用机制------即针对较为简单的查询任务，将其路由至成本更低的模型进行处理------系统在保持与 GPT-4 相当的性能水平的同时，可实现高达 98% 的成本削减。GPTCache（Bang, 2023）则通过引入语义缓存层，对上述优化策略进行了有效补充。该缓存层能够在查询请求抵达 LLM 之前，拦截那些重复出现或仅是表述方式有所变化的查询，并利用嵌入向量（Embedding）的相似度匹配技术，直接从缓存中检索并返回预存的响应结果。综合来看，查询路由与语义缓存已成为生产环境中成本优化堆栈里两个核心且通用的构建模块；它们可直接应用于 Agent 框架层面的精细化监控与调控（Instrumentation），从而实现对框架内每一次工具调用及每一次上下文组装步骤的独立计量与动态路由。
QC-Opt（Shekhar et al., 2024）在既有的路由范式基础上进行了扩展，提出了一套"质量感知型"的优化框架。该框架能够在既定的预算约束下，对模型选型、Token 消耗量以及响应延迟这三个关键指标进行联合优化；其核心机制在于利用 BertScore 预测器来预估模型的输出质量，从而避免了为进行质量评估而不得不实际调用目标 LLM 所带来的额外开销。此外，TALE（Han et al., 2025）研究团队所揭示的"Token 弹性"现象，揭示了一个至关重要的细节：若在执行"思维链"（Chain-of-Thought）推理任务时，人为设定的 Token 预算上限过低，反而可能产生适得其反的效果------即导致实际的 Token 消耗量不降反升。这是因为当模型因预算不足而被迫"溢出"时，其最终生成的 Token 数量反而会超过那些采用了适度预算设定的提示词所产生的 Token 数量。而在基础设施层面，Dual-Pool Token-Budget Routing（Liu，2026b）方案从服务侧着手解决成本问题，将同质化的 vLLM 集群划分为短上下文池和长上下文池，并根据估算的 Token 预算对请求进行路由。基于 Azure LLM 推理追踪数据和 LMSYS-Chat-1M 数据集的评估结果显示，该方法可将 GPU 工时减少 31% 至 42%（若应用于 A100 规模的集群，预计每年可节省 286 万美元）。
对于驾驭（Harness）工程师而言，这意味着成本的可观测性必须涵盖多个层面：API 层的 Token 追踪（如 Helicone、TensorZero）、应用层的路由决策（如 FrugalGPT、QC-Opt），以及基础设施层的资源利用情况（如双池调度 Dual-Pool、KV 缓存占用率）。Anthropic 关于智体编程评估中"基础设施噪声"的研究（Anthropic 2026a）提供一个警示性的补充案例：仅仅是基础设施配置的差异，就可能导致基准测试得分产生 6 个百分点的波动（p < 0.01）。这一发现表明，成本优化与评估的保真度之间存在紧密的内在联系；因为为了节省成本而削减资源，可能会在无形中降低智体的性能，且若缺乏细粒度的可观测性，这种性能退化往往难以被察觉。
4 可靠性工程
故障恢复、检查点/恢复机制、重试策略以及会话恢复等问题，属于驾驭层面的关键考量，它们决定了长时间运行的智体能否在遭遇瞬时故障时继续存活并正常工作。当智体跨越多个"上下文窗口"（Context Window）进行操作时，上述问题便会变得尤为突出------因为在跨窗口场景下，每一个新的会话启动时，往往都无法保留此前会话的任何记忆（Anthropic 2025d）。Anthropic 针对驾驭工程开展的研究，识别出了长时间运行的编程智体在工作中反复出现的四种故障模式：智体试图一次性完成整个任务；智体过早地宣告项目已完成；智体在两次会话切换之间，将环境遗留在了某种损坏或不可用的状态；以及智体在未经过充分测试的情况下，便将特定功能（Feature）标记为已完成。Anthropic 提出的两阶段解决方案（Anthropic 2025d）并未试图改进模型本身，而是通过优化驾驭的设计，直接有效地解决了上述可靠性难题。该方案首先引入一个"初始化智体"（Initializer Agent），负责将整体任务拆解为结构化的功能清单，并预置一系列用于追踪进度的辅助资产（Artifacts），包括 Git 仓库、进度记录文件以及初始化脚本等；随后，一个"编程智体"（Coding Agent）将接手工作，以增量迭代的方式逐一完成各项功能，并在每次任务切换时确保环境处于一种"干净"且可顺利交接的状态。
随后的相关研究进一步拓展并深化了这一设计模式。Anthropic 团队受生成对抗网络（GAN）架构启发而构建的"三智体架构"（包含规划者、生成者与评估者三个角色），引入了"冲刺契约"（Sprint Contracts）机制以及独立的自我评估环节，旨在有效遏制智能体往往倾向于过度夸耀自身工作成果的固有倾向（Anthropic 2026c）。值得注意的是，作者们证明了驾驭（harness）的复杂程度应当与模型的实际能力相匹配：在将模型从 Opus 4.5 升级至 Opus 4.6 的过程中，他们彻底移除"冲刺"（sprint）结构和上下文重置机制，从而将运行成本从 200 美元降至 125 美元，同时却保持输出质量不受影响。这揭示一个普遍原则：驾驭中的每一个组件都内含着一种假设------即假定模型在缺乏辅助的情况下无法独立完成某项任务；然而，随着模型能力的不断提升，这些基于过往能力的假设往往会变得过时失效。
在基础设施层面，Anthropic 提出的"托管智体"（Managed Agents）架构（Anthropic, 2026b）将智体的"大脑"（即驾驭与大语言模型 LLM 的结合体）与"双手"（即沙盒环境与各类工具）以及"会话"（即持久化的事件日志）进行了彻底解耦，从而确保了每一个组件都能独立地进行故障恢复。若驾驭发生崩溃，系统可通过调用 wake(sessionId) 指令重启一个新的实例，并从会话日志中记录的最后一个事件处继续执行任务。若沙盒环境发生故障，驾驭能将其识别为一次"工具调用失败"的错误，并随即自动配置一个新的沙盒环境来替代。此外，各类敏感凭据均统一存储于外部的密钥保险库中，绝不会被直接置入沙盒环境内部。这一架构设计将所有组件的角色从"宠物"（即不可替代、需人工精心照料的实例）转变为"牲畜"（即可相互替换、由系统自动重新配置的实例），而这正是实现智能体大规模、高可靠运行所必须具备的前提条件。
学术界的相关文献已针对可靠性工程领域必须应对的各类故障模式，构建了详尽的分类体系。例如，MAST 框架（Cemri et al., 2025）识别了多智能体系统中存在的 14 种故障模式，并将其归纳为三大类：系统设计缺陷、智能体间协作失调，以及任务验证环节的问题（该分类体系的 κ 一致性系数高达 0.88）。另一项研究 AgentErrorTaxonomy（Zhu et al., 2025）则依据功能模块（涵盖记忆、反思、规划、行动及系统层面）对故障进行了细致拆解；研究结果表明，"错误传播"（即单一的根本性故障像多米诺骨牌般层层扩散，最终导致后续决策全盘崩溃的现象）是制约智能体可靠性的核心瓶颈所在。该团队提出的 AgentDebug 调试框架，通过精准定位并隔离故障的根本原因（而非仅仅针对表面症状进行修补），成功将任务的成功率相对提升高达 26%。与此同时，Vinay（2025）针对大语言模型（LLM）在实际生产环境中部署应用时所特有的隐性故障模式，构建一套包含 15 种具体类型的系统级分类体系。这些故障模式包括："版本漂移"（即模型在更新迭代后，其行为表现发生静默且非预期的改变）、"成本驱动型性能崩溃"（即为了追求极致的成本效益而采取激进的优化手段，最终导致模型输出质量严重下滑），以及"多步推理漂移"（即在处理长序列任务时，模型的逻辑连贯性随推理步骤的增加而逐渐丧失）等。 QSAF Atta（2025）将认知退化正式建模为一个六阶段的生命周期，并跨越五个大语言模型（LLM）平台对其进行验证；研究揭示，幻觉输出可能会被存储在持久性记忆中，并在未来的会话中被重复利用，从而形成跨越会话边界的自我强化退化循环。
在运行时检测方面，SentinelAgent（He，2025）将多智体交互建模为图结构，并利用"LLM 作为裁判"（LLM-as-judge）结合"人工参与的策略优化"（human-in-the-loop policy refinement）机制，将异常分为三个层级进行分类（全局层、单点层、多点层）。AgentFixer（Mulian，2026）在 IBM 的 CUGA 生产系统中部署 15 种验证工具，实现了 64% 至 88% 的问题检测率；研究发现，38% 的任务失败可归因于解析错误------这是一种完全可以通过确定性检查来解决的故障模式。其现实意义在于，若要确保智能体的可靠性，必须采取分层检测策略：针对结构性故障（如工具调用格式错误、架构违规）采用轻量级的基于规则的检查；针对性能漂移（如延迟、Token 用量、成本趋势）进行统计监控；针对推理故障（如幻觉、规划与行动脱节、过早终止）进行基于 LLM 的语义分析。
5 讨论：迈向统一的可观测性
可观测性与评估之间的鸿沟。LangChain 调查报告中呈现的 89% 与 52% 的数据分化，反映出一种结构性的脱节：追踪数据收集工具与评估框架在很大程度上是由不同的社区开发的，且彼此采用了不同的接口。弥合这一鸿沟需要更紧密的集成，例如：根据生产环境中的故障追踪数据自动生成回归测试用例；或者将在线评估得分作为触发告警的信号。无论是 LangChain 自身关于深度智能体评估的分析（LangChain，2025a），还是 Anthropic 对基础设施噪声的量化研究（Anthropic，2026a），两者均主张：评估与可观测性必须被视为一个统一的反馈闭环，而非两个相互独立的关注点。
统一的 LLMOps 技术栈。TensorZero 和 Langfuse 等工具正致力于将网关、可观测性、评估及优化功能整合至单一平台之中，从而降低集成的开销。NLAH 框架在此基础上更进一步，将智能体运行框架（harness）本身设计为模块化且具备自省能力的结构，通过"消融实验"（ablation）即可量化各组件所做出的贡献。Anthropic 的"托管智体"（Managed Agents）架构则采取了基础设施层面的视角，将运行框架中的组件抽象并虚拟化为可替换的接口（如 execute()、emitEvent()、getEvents()）；这种设计能够兼容未来的运行框架设计方案，而无需对周边的系统环境进行任何改动。
"驾驭即假设"原则。驾驭（Harness）的每一个组件都内含一种假设，即假定模型在独立运行时存在某些无能为力之处（Anthropic, 2026c）。随着模型能力的提升，可观测性系统不仅需要监测智体何时发生故障，还必须识别出 Harness 组件何时已沦为不必要的冗余开销。理想的可观测性系统应包含一个"元监控"层，用于追踪哪些干预措施（例如上下文重置、评估器反馈回路、工具使用限制等）依然发挥着实质性的支撑作用，从而确保在模型升级的同时，能够持续对 Harness 进行精简优化。
验证与评估（V）是 ETCLOVG 框架的第六大支柱。
1 将评估构建为"任务-反馈"生命周期
一种具备"驾驭（harness）-觉察"的评估方法，应当将报告的得分视为模型-驾驭这一组合体的属性，而非仅视为模型自身的属性。这一理念推动了特定评估协议的制定：要么在针对不同模型进行评估时锁定驾驭保持不变，要么将驾驭的配置变化作为一个明确的实验变量来加以考量（Bölük, 2026b）。将驾驭的评估过程组织为一个"任务-反馈"生命周期：这是一个结构化的流程，始于明确定义智体（agent）所需执行的任务，终于将评估结果反馈回驾驭的改进工作中。如图 12 概述这一包含五个阶段的"任务-反馈"生命周期。该生命周期的构建基础，在于传统的大语言模型（LLM）评估与智体评估之间存在着一个关键差异。传统的 LLM 评估主要针对固定输入所产生的输出进行评分；相比之下，驾驭的评估所衡量的是一个完整的"执行回合"（execution episode）：即任务被置于特定的环境中，智体在时间轴上与各类工具及环境状态进行交互，其执行轨迹被全程捕获，最终评估者不仅会对最终结果进行判定，还会对达成该结果所经历的执行路径进行评判（Kapoor et al., 2025; Anthropic, 2026b; LangChain, 2025b）。
构建这一生命周期的核心动因在于：评估基础设施中存在的"噪声"往往会伪装成模型的故障。具体而言，一次失败的运行结果可能不仅仅反映了模型的局限性，还可能归因于工具损坏、上下文信息过时、沙盒环境未重置、测试用例不稳定（flaky tests）、基准测试标准含糊不清，或是评估判官（judges）工作不稳定等基础设施层面的问题（Kapoor et al., 2025; Hu et al., 2025a; Jimenez et al., 2024）。因此，评估工作不应仅仅止步于报告一个最终得分，而应当将智体的行为转化为结构化的判定结论、故障归因分析以及用于回归测试的反馈信息。
这一包含五个阶段的分解结构，正是依据智体评估运行过程中的因果逻辑路径来设计的。在对智体进行正式评估之前，基准测试体系必须首先明确规定任务内容、运行环境、可用工具、各项约束条件以及成功的判定标准。在执行任务之前，必须对整个评估设置进行有效性验证，以确保环境故障或评分机制故障不会被误判为模型自身的故障。在任务执行期间，驾驭必须全程捕获智体的执行轨迹（traces），从而确保该次运行过程具备可诊断性。在任务执行完毕之后，系统必须对最终结果、执行轨迹以及评估判官的可靠性进行综合判定，进而将检测的故障归因于评估套件中最为可疑的特定组件。最后，得出的诊断结果应当反馈回回归测试及后续的驾驭（harness）修订工作中。从这一视角来看，评估并非一个终结性的评分环节，而是一个贯穿整个智体驾驭的质量控制闭环。
围绕五个阶段展开讨论：
• 任务与基准确立（Task and Benchmark Grounding）：明确评估对象为何，在何种环境中进行，以及所使用的工具、约束条件和成功判定标准。
• 执行前就绪性验证（Pre-execution Readiness Validation）：在智体正式运行前，检查沙箱环境、依赖项、工具集、上下文状态、权限策略、资源预算及评分模块是否均已正确初始化。
• 受控执行与轨迹捕获（Controlled Execution and Trace Capture）：在可复现的条件下运行智体，并同步记录模型的输出、工具调用、状态变更、错误信息、重试尝试、运行成本及延迟指标。
• 多层级判定与故障归因（Multi-level Judgement and Failure Attribution）：从运行结果、执行轨迹及评估模块等多个层级对运行过程进行综合评估，进而定位整个驾驭技术栈中潜在的故障源头。
• 持续回归与部署反馈（Continuous Regression and Deployment Feedback）：将评估结果转化为回归测试用例、监控信号及工程反馈，以此指导后续的驾驭修订与迭代工作。
2 第一阶段：任务与基准确立
第一阶段旨在回答核心问题：究竟在评估什么？对于大语言模型（LLM）智能体而言，所谓的"任务"绝非仅仅是一条自然语言提示词（prompt）；它实际上是一个内嵌于特定情境中的问题，其定义要素涵盖了环境状态、可用工具集、允许执行的动作、各类约束条件、终止判定条件，以及最终的成功判定标准。因此，"任务确立"（Task Grounding）构成了整个驾驭评估工作的基石：若缺乏明确界定的运行环境与成功判定标准，后续得出的各项评分数据将无法进行可靠的解读与分析。
3 第二阶段：执行前就绪性验证
第二阶段旨在确认评估过程能否以公平且可复现的方式顺利进行。尽管这一阶段在基准测试排行榜中往往隐而不显，但它却是整个驾驭（Harness）运作的核心所在。在智体（Agent）正式启动之前，驾驭必须对环境、工具、上下文状态、权限边界、预算限制以及评估器进行验证，确保其均已正确初始化。若缺失这一就绪性验证层，后续出现的故障将难以归因：一次运行失败可能确实归因于智体本身，但也完全可能是由评估环境的配置设置所致。
4 第三阶段：受控执行与轨迹捕获
第三阶段旨在探究执行过程中究竟发生了什么。在传统的 LLM 评估中，佐证材料可能仅由单一的输入-输出对构成；而在智体（Agent）评估中，所谓的"轨迹"则是一条多步骤的执行路径：模型在此过程中观察状态、进行推理、调用工具、接收工具输出、修改环境、处理错误，并最终终止运行。因此，若要将基准测试的运行过程转化为可供诊断的佐证材料，受控执行与轨迹捕获便显得必不可少。
5 第四阶段：多层级判定与故障归因
在完成受控执行与轨迹捕获之后，核心问题在于应如何对此次运行进行判定；若运行失败，又该如何对故障进行定位。将第四阶段定义为一个集"多层级判定"与"故障归因"于一体的综合流程。其中，多层级判定将从三个层面评估此次运行的表现：最终结果是否正确、运行轨迹是否高效且符合策略要求、以及评估器本身是否可靠。随后，故障归因环节将利用上述信号进行诊断，以确定故障最可能源自何处------例如模型、工具接口、上下文管理器、执行环境、编排循环、基准测试规范，抑或是评估器本身。正是这一阶段，构成了"驾驭（Harness）评估"与"普通基准测试评估"之间的本质区别：其目标绝非仅仅赋予一个分数，而是要将执行过程中产生的各类证据转化为具有实际指导意义的工程诊断结论。
6 第五阶段：持续回归与部署反馈
最后一个阶段探讨评估结果如何驱动驾驭（harness）的下一轮修订。智体驾驭处于持续演进之中：提示词、工具架构、MCP 服务器、上下文策略、沙箱镜像、编排循环、治理规则以及判官提示词，都可能随时间发生变化。持续评估机制将基准测试结果与生产环境中的故障转化为针对驾驭本身的回归测试体系。
7 总结
验证与评估层的作用，是将智体（Agent）的行为转化为工程化的证据。将这一层架构为一个"任务-反馈"的生命周期。第一阶段将任务置于现实环境中，并确立明确的成功标准。第二阶段验证评估设置是否已就绪、是否公平且具有可复现性。第三阶段执行受控的运行部署（Rollout），并捕获运行轨迹数据。第四阶段从结果、运行轨迹以及评估器这三个层面，对每一次运行进行判定与分析。第五阶段将评估结果反馈至持续回归测试流程中，并用于改进智体驾驭（Harness）。
这一生命周期将评估的定位进行重构：它不再仅仅是一种基于排行榜的排名机制，而是演变为一套针对智体驾驭的质量控制闭环。虽然最终的成功率依然具有参考价值，但它已不再足以满足需求。对于需要长期运行的智体而言，评估的核心问题不再仅仅局限于"智体是否成功完成了任务"，而是进一步探究：它为何成功或失败？其执行路径是否可接受？评估器本身是否值得信赖？以及接下来应当优先改进测试框架中的哪一组件？
驾驭和安全旨在探讨如何对智体的行为施加约束、确保其安全性并落实问责机制。如今，大语言模型（LLM）智体已能执行 Shell 命令、发送电子邮件、提交代码以及调用第三方 API；对于生产环境的部署而言，核心问题在于：智体的行为应受何种约束？一旦这些约束失效，又应由谁来承担责任？在生产系统中，治理工作拥有其专属的工具生态系统，其中包括权限引擎、策略语言、审计流水线以及网关控制组件。这一生态系统有别于生命周期钩子与可观测性基础设施，因此在 ETCLOVG 分类体系中，理应将其作为一个独立的层级来加以论述。
1 权限模型与身份管理
对于任何智体驾驭（Agent Harness）而言，首要的治理问题便是访问控制：即智体能够访问哪些工具、文件、网络端点及系统资源？相较于传统的基于角色的访问控制（RBAC）或基于属性的访问控制（ABAC），智体工作负载使这一问题变得更为棘手；原因在于，智体所需的工具集往往取决于一项以自然语言描述的任务，而该任务的具体内容在部署时通常是未知的。因此，相关研究文献在权限粒度的维度上呈现出一种演进趋势：从部署时即固定的"静态边界"，过渡到针对每一次工具调用进行评估的"上下文相关策略"，进而扩展至针对本地运行环境之外交互行为的"跨边界权限"。
静态权限边界。生产环境中的代码生成智体通常会预先定义一个权限范围，并要求针对超出该范围的操作进行权限提升（escalation）。例如，Codex（OpenAI, 2025）在一个沙箱环境中执行 Shell 命令，该沙箱对文件系统和网络访问施加了严格限制；而 Gemini CLI（Mullen & Salva, 2025）则将工作区范围内的文件访问权限与命令的"允许/拒绝"列表相结合。尽管此类边界易于审查与管理，但它们无法表达针对特定任务的意图。
若要突破这种固定的规则限制，就必须能够表达那些依赖于每一次工具调用之运行时上下文的约束条件。
上下文相关的权限控制。Progent（Shi et al., 2025a）引入一种域特定语言（DSL），其谓词（predicates）可涵盖工具名称、参数以及环境状态等要素。运行时环境会在每一次工具调用执行前对这些谓词进行评估，从而使"最小权限"策略能够根据角色、用户或会话的不同而动态调整。Conseca（Tsai & Bagdasarian, 2025）进一步深化了这一理念：它基于可信的上下文信息生成针对特定任务的策略，并利用一个独立的、确定性的检查器来强制执行该策略。这种将策略生成与策略执行相分离的设计至关重要：生成组件能够灵活地适应具体的任务需求，而执行组件则始终保持其可审计性。
上述各类方法均是在单一智体的边界范围内运作的。而在多智体协作的场景下，访问控制与智体身份管理这两方面均面临着更为严峻的挑战。
身份管理与智体间访问控制。在授予访问权限之前，系统必须首先明确提出访问请求的主体究竟是谁。South（2025）提出，智体系统亟需一种"经认证的委托机制"（authenticated delegation）：即构建一个在 OAuth 2.0 和 OpenID Connect 协议基础上进行扩展的框架，引入"用户 ID token"、"智体 ID token"以及具有特定作用域的"委托token"，从而将用户的意图与针对特定智体的权限紧密关联起来。这种token链将建立一条从人类委托人到智体行动的、可验证的责任追踪链。SAGA（Syros，2025）基于这一原则，通过一种由提供商介导的架构，将其应用于多智体场景。智体使用加密的一次性密钥进行注册，而短生命周期的访问令牌则用于强制执行智体之间用户定义的交互策略。IsolateGPT（Wu，2025）采取一种架构层面的方案，采用"中心-辐射"（hub-and-spoke）模型：每个第三方应用程序都在一个独立的"辐射"节点中运行，并拥有各自独立的 LLM、记忆及工具访问权限。节点间的通信必须通过一个受信任的"中心"节点进行中转，从而使跨应用程序的数据交换成为一种明确的治理决策，而非共享上下文窗口所带来的附带副作用。
凭据管理。智体日常工作中经常需要处理 API 密钥、会话token和一次性密码等凭据。若将这些凭据直接暴露在 LLM 的上下文环境中，将引发数据泄露的风险。Skyvern（Skyvern-AI，2025）展示了一种通用的解决方案模式：将敏感密钥存储在专门的"密钥保险库"中，仅向 LLM 暴露占位符，只有在执行经身份验证的操作时，才在自动化执行层将占位符替换为真实的密钥数值。目前尚未解决的一个难题是针对长周期会话的密钥生命周期管理：在此类会话过程中，token可能会中途过期或被撤销，而更新后的凭据仍需严格置于模型上下文环境之外。
Web 层面的权限协调。上述机制均在单一智体驾驭（harness）的信任边界内运作，并仅对该框架内部的部署实例进行管理。然而，在涉及跨组织的交互场景中------即智体需要访问第三方网站或调用由其他方提供的服务时------仅凭单一的智体运行框架将无法独立实施所需的权限协调。Marro（2025）提出一种名为 agent-permissions.json 的轻量级清单文件，其功能类似于 Web 领域的 robots.txt 文件。网站所有者可通过该清单文件声明智体可操作的 UI 元素、访问速率限制、并发约束，以及哪些操作需要经过人工确认。尽管此类清单文件本身并不能解决身份认证的问题，但它们生动地展示了治理机制如何开始跨越组织边界进行延伸。
尚待解决的挑战。如何设计出既富有表达力又具备实用性的权限模型，目前仍是一个悬而未决的难题。若权限策略过于严格，将导致智体的效用大打折扣；反之，若策略过于宽松，则将彻底消解治理机制存在的初衷。目前，业界尚未就一套标准的权限规范语言达成共识，从而无法确保该语言在不同的智体运行框架实现之间具备通用的可移植性。此外，关于相关行动究竟应归因于人类操作员、智体实例，还是瞬时任务身份，目前仍存在悬而未决的问题（South et al., 2025）。
2 生命周期钩子
权限模型定义"允许做什么"，而生命周期钩子则定义"何时触发策略检查"。许多智体驾驭（harnesses）在智体循环的各个阶段都暴露钩子点：规划之前、工具调用之前、工具执行之后，以及响应交付之前。这些钩子允许在不修改代理核心推理逻辑的前提下，注入治理逻辑。图14展示这四个钩子点在单个工具使用周期中的位置。
执行前钩子：输入防护栏。输入防护栏在数据到达大语言模型（LLM）之前对其进行验证。PromptShield (Jacob et al., 2024) 和 DataSentinel (Liu et al., 2025) 训练了专门的分类器，用于检测用户输入及检索内容中的"提示注入"（prompt injection）攻击载荷。基于规则的检测器虽然严格，但也较为脆弱；而基于模型的检测器泛化能力更强，但速度较慢，且容易受到自适应攻击的影响 (Andriushchenko et al., 2024; Nasr et al., 2025)。
下一个强制执行点位于 LLM 提出的动作与智体驾驭执行工具动作之间。
调用前钩子：输出防护栏与动作验证。在执行工具调用之前，输出防护栏会对 LLM 提出的动作进行检查。ShieldAgent (Chen et al., 2025b) 将安全约束形式化为可验证的谓词，并针对这些谓词对每一个动作进行检查。在多智体系统中，ControlValve (Jha et al., 2025) 对智体之间的控制流图进行约束，防止未经授权的智体间跳转，从而应对"控制流劫持"攻击------即某个智体将执行流程重定向至另一个智体的攻击形式。
工具执行完毕后，返回的数据在重新进入 LLM 的上下文之前，也必须经过检查。
执行后钩子：信息流控制与污点追踪。CaMeL (Debenedetti et al., 2025) 实现了一种基于能力的（capability-based）信息流控制机制。每一个数据值都携带着元数据标签以追踪其来源，从而区分受信任的用户输入与不受信任的网络检索内容。一个自定义的解释器负责强制执行规则，确保不受信任的数据无法影响控制流决策。CaMeL 将基于受信任上下文的规划过程，与基于不受信任内容的处理过程隔离开来；在 AgentDojo 框架 (Debenedetti et al., 2024) 中，这种设计通过牺牲部分灵活性，换取了更强的控制流与数据流边界。一种补充性的执行机制将人类用户纳入了决策循环之中。
"人机协作"（Human-in-the-loop）挂钩机制。几种广泛使用的编程智体工具------包括 Codex、Gemini CLI、Cursor 和 OpenHands (Wang et al., 2025a)------均要求用户明确批准，以此来把控那些具有破坏性或超出预定范围的操作。有三个设计维度共同塑造这些挂钩机制：验证范围（即哪些操作需要批准）、警报丰富度（即用户能看到的上下文信息量），以及重复策略（即是"仅允许一次"还是"始终允许"）。Felt 等人 (2012) 的研究表明，仅有 17% 的 Android 用户在应用安装过程中会留意权限对话框，且仅有 3% 的用户能正确回答关于其已授予权限的理解性问题；智体工具的审批对话框也可能面临类似的"习以为常"和"难以理解"的风险。过于频繁的审批请求会导致用户下意识地批准危险操作，而请求频率过低则可能导致安全防护出现空白。
某些系统将挂钩机制视为一种可编程的执行基础架构，而非孤立的分类器。AgentSpec (Wang et al., 2026) 在规划、工具调用和响应这三个阶段，通过定义包含触发条件、判定谓词和执行动作的规则来实现管控。AgentDoG (Liu et al., 2026a) 则将防护重心从针对单一操作的分类判定，转移到了针对整个操作轨迹（trajectory-level）的综合诊断上，并依据风险的来源、失效模式及其后果对各类风险进行归类整理。
尚待解决的挑战。纵观当前的各类系统，其挂钩 API 仍呈现出高度异构的状态。目前尚未出现任何被广泛采纳的标准，能够为第三方治理模块定义一套通用的挂钩接口。此外，挂钩机制还会引入额外的延迟；而当多个挂钩机制层叠使用时，它们之间产生的交互效应目前也鲜有研究。一种潜在的失效模式是：上游的"净化器"（sanitizer）在处理过程中改变了下游"检测器"（detector）所依赖的信号特征，从而导致整个组合式防护管道的整体安全性，反而弱于单独使用其中任何一个组件时的安全性。
3 组件加固
生命周期挂钩机制主要在"驾驭层"（harness level）实施治理与管控。而"组件加固"技术则是针对智体工具中的各个独立组件------特别是大语言模型（LLM）及其调用的各类工具------进行强化，旨在抵御这些组件自身所特有的安全漏洞。通过采用经过加固的组件，整个智体驾驭（harness）将从中获益，因为这样一来，能够成功绕过组件层防护并最终触发框架层治理挂钩的恶意输入，其数量将大幅减少。
模型加固。提示注入（Prompt Injection）的一个根本原因在于，大型语言模型（LLMs）对所有输入文本一视同仁，无法区分系统指令与非受信任数据。Wallace（2024）提出了一种"指令层级"机制，通过训练使模型优先执行高权限指令（即系统提示），而非低权限指令（如用户消息、工具输出）。模型学会了在低层级指令与高层级约束保持一致时予以遵从，而在发生冲突时则予以忽略或拒绝。SecAlign（Chen，2025a）将这一防御目标转化为一种"偏好优化"问题，即通过对包含提示注入的输入、理想响应以及非理想响应进行优化训练来实现防御。
这些模型层面的防御手段与"Harness"层面的钩子机制相辅相成。经过加固的模型能够在推理阶段拦截更多的注入攻击，从而减轻下游安全护栏（Guardrails）的负担。然而，仅凭模型加固尚不足够：尽管它解决了 （Kim，2026）所归类的"错误指令执行"问题，却无法阻止不受约束的数据流转或未经授权的操作------这些问题需要通过系统层面的强制执行机制来解决（Kim，2026；Wei，2026）。
基于分类器的运行时加固。另一类互补性的研究工作旨在加固模型边界，且无需修改作为智体核心的 LLM 本身；其做法是部署小型辅助分类器，在运行时对输入和输出进行筛查。Llama Guard（Inan，2023）通过微调一个独立的模型，依据一套可配置的安全分类体系，对用户提示和助手响应进行分类；该模型会针对每个类别输出相应的标签，Harness 框架可依据这些标签来决定是允许、拦截还是上报相关操作。此类分类器具备两项训练阶段加固手段所不具备的实用特性：一是无需对智体模型进行重新训练，即可对安全分类体系进行编辑；二是同一个检测器可在异构的 LLM 后端之间复用。其代价在于"延迟预算"问题：每增加一个分类器，在每个工具调用周期中就会增加一次前向传播计算。
模型层面的防御与分类器防御主要用于加固 LLM 的边界；而工具边界则需要采用专门的协议层级处理手段。
工具加固与 MCP 安全。模型上下文协议（Model Context Protocol，简称 MCP；Anthropic，2024c）已成为智能体与工具之间通用的接口标准，但其初始规范中尚缺乏原生的安全原语支持。这一安全漏洞既引发了针对性的攻击与防御，也促使官方发布了相应的规范响应。Radosevich 与 Halloran (2025) 演示指出，广泛使用的商业大语言模型（LLM）可能会在胁迫下利用 MCP 工具来执行恶意代码、建立远程访问通道并窃取凭据。他们开发的 McpSafetyScanner 工具采用了一种"三智体"架构（包含黑客、审计员和监督员角色），旨在系统性地挖掘此类安全漏洞。Trail of Bits (2025) 的研究表明，MCP 服务器甚至可以在用户尚未主动调用工具之前，就通过"投毒"的工具描述信息来影响 LLM 的行为（即在工具注册阶段进行干预），从而对客户端发起攻击。
在防御层面，ETDI (Bhatt et al., 2025) 扩展了 MCP 框架，引入了经密码学签名且具备版本控制的工具定义机制；该机制确保对工具代码、架构或权限的任何修改都必须生成一个新的签名版本。这一设计有效防范了所谓的"地毯式撤资"（rug-pull）攻击------即攻击者悄无声息地更新此前已获批准的工具，使其转而执行恶意操作。
协议层面的加固。除了针对单个组件的防护外，SAFEFLOW (Li et al., 2025) 还针对多智能体系统引入了协议层面的强制执行机制。该系统将细粒度的信息流控制与事务性执行语义相结合，从而确保任何违规的工具调用或智体间消息都能被回展撤销，而非通过共享状态在系统中扩散蔓延。
供应链风险。智体治理工作还必须涵盖智体所调用的各类工具与软件包。Spracklen (2025) 对跨越 16 种不同 LLM 的 576,000 个代码样本进行了分析，结果发现开源模型在生成实际不存在的软件包名称方面，其"幻觉"发生率高达 21.7%。攻击者可以抢先在公共代码仓库中注册这些虚构的软件包名称，并向其中注入恶意代码；这种攻击手法被称为"slopsquatting"（即利用模型失误进行抢注攻击）。尽管 ETDI 引入的密码学签名机制在一定程度上解决了 MCP 工具面临的此类问题，但在大多数现有的智体治理体系中，软件包管理器及相关的代码检索源仍处于防护盲区之外。
尚待解决的挑战。针对模型的加固（Model hardening）与针对工具的加固（Tool hardening）分别应对着互为补充的不同威胁面，但目前尚缺乏一个能够将二者有机整合的统一框架。即使模型本身已通过加固变得足够健壮，它仍有可能误调用已被攻陷的恶意工具；反之，即便工具定义文件已通过签名机制得到保护，也无法阻止那些已被"越狱"（jailbroken）的模型对该工具进行恶意滥用。如何将上述各类防御手段整合成一个逻辑连贯的防护体系，并能对其中残余的风险进行量化评估，目前仍是一个有待攻克的开放性难题。随着 MCP 采用率的不断提升，其安全扩展功能自然而然地成为了标准化的目标；然而，互操作性与认证方面的问题在很大程度上仍未得到解决。
4 声明式章程
将治理逻辑直接嵌入应用程序代码中，会导致策略变得不透明、难以审计且难以更新。越来越多的智体驾驭（harnesses）将治理规则外部化为声明式配置文件，其中最常见的是 YAML 格式。这些文件充当了智体的"机器可读宪法"。
训练期宪法：Anthropic 的"宪法式 AI"（Constitutional AI）。Anthropic (Anthropic, 2026a) 发布了一份宪法，其结构按优先级划分为四个层级：安全性（维护人类监督）、伦理（诚实、避免伤害）、合规性（Anthropic 的内部准则）以及有用性（满足用户请求）。该宪法区分了"硬约束"------例如对提供化学、生物、放射性和核（CBRN）相关协助的绝对禁令------与"软编码默认值"，后者允许操作者在既定范围内进行调整。在智体应用场景中，这种结构确立了一种优先级层级：Anthropic 的策略优先于操作者的配置，而操作者的配置又优先于终端用户的偏好。
训练期宪法通过在模型对齐（alignment）及后训练阶段塑造模型的行为来发挥作用。它们在训练阶段对模型行为进行定型，但在部署之后难以修改，且无法由智体框架进行独立审计。另一种截然不同的方法是将治理规则外部化为"部署期配置"，智体驾驭能够读取、验证并强制执行这些配置。
部署期宪法：基于 YAML 的治理。AutoHarness 代码库 (AIMing Lab, 2026) 将治理规则编码在一个 YAML 文件中，该文件规定管道模式（核心、标准或增强）、风险分类模式、允许及禁止的工具模式、Token 预算限制以及审计日志的存储位置。这种声明式风格将治理意图与执行逻辑分离开来。非开发人员的利益相关者（如安全团队和合规专员）无需触碰智体的代码，即可审查和修改策略。与训练期宪法不同，YAML 文件可以使用标准工具进行更新、版本管理及差异比对（diff），从而实现在无需对模型进行重新训练或重新部署的情况下更新策略。
这两个层级在操作层面存在显著差异。修改训练期宪法的成本高昂，且其具体内容必须通过行为探测（behavioral probes）进行反向推断；而部署期的 YAML 文件则可直接读取，并支持差异比对审查。训练期的对齐过程以概率方式塑造模型的默认行为，且容易被对抗性提示（adversarial prompts）所绕过 (Andriushchenko et al., 2024)；部署时规则则作为驾驭（Harness）的检查项来运行。
当策略仅归结为字面触发条件时，基于模式的 YAML 规则便已足够；但实际的部署往往需要针对运行时状态应用条件逻辑。当前的 YAML 模式尚未对涉及权限提升、基于主机的出站流量、会话级速率限制或未来动作的谓词进行标准化定义。介于自由形式的 YAML 与硬编码规则之间，存在第三种设计方案：结构化的策略 DSL（领域特定语言）。
可编程策略语言。Progent 的策略语言（Shi，2025a）支持布尔谓词、量词以及环境引用。它在保持可读性的同时，提供了严谨的形式化表达能力。Formal-LLM（Li，2024）更进一步，将规划约束编码为下推自动机。这种形式化方法能够表达顺序约束、禁止的工具组合，以及特定步骤中所需的审批关卡。VeriSafeAgent（Lee，2025）将用户意图形式化为一种基于 UI 状态转换的 DSL，从而在执行前验证拟议的 GUI 操作是否与用户的任务目标相一致。YAML 宪章（Constitutions）往往存在歧义；而形式化规范则要求具备专业知识。
尚待解决的挑战。目前尚无被广泛采纳的智体宪章标准模式。各个驾驭往往各自定义一套 YAML 结构，导致策略缺乏可移植性。在当前生态系统中，用于验证宪章是否具有内部一致性（例如，不存在相互矛盾的允许/拒绝规则）及完整性（例如，未遗漏任何工具类别）的辅助工具显得十分匮乏。训练时宪章与部署时宪章之间的交互关系，尤其是一个尚未得到充分探索的领域。一条 YAML 拒绝规则能否可靠地覆盖经由 RLHF（基于人类反馈的强化学习）所强化的某种行为？以及在何种条件下这两层规则会发生冲突？这些问题不仅仍是悬而未决的难题，更具有切实的现实安全隐患。
5 审计基础设施
治理要求问责。审计基础设施记录了智体执行了什么操作、为何执行该操作，以及是否遵守了治理策略。这些记录为事后调查、合规监管以及持续的策略优化提供了支持。
结构化的审计追踪。AutoHarness（AIMing Lab, 2026）针对每一次工具调用生成 JSONL 格式的记录，其中包含工具名称、参数、风险分类、权限决策、执行结果、Token 消耗量以及实际耗时（wall-clock latency）。这些结构化日志既支持实时仪表盘展示，也支持离线取证分析。SAGA（Syros, 2025）将审计追踪的范围扩展至多智体交互场景，通过记录智体之间交换的加密令牌，实现了跨信任边界的溯源追踪。在上述各类系统中，一份可重放的审计记录至少应包含：追踪标识符、主体身份、工具调用详情、策略决策及其版本、执行结果、资源消耗情况，以及针对相关输入与输出数据计算得出的完整性哈希值。目前大多数系统仅记录上述字段中的一部分，且鲜有系统会对审计记录进行签名或哈希处理，这使得审计追踪极易遭受受损智体进程的日志篡改攻击。
除了单纯的记录之外，若要检测长期运行的智体是否存在治理违规行为，还需要借助自动化分析手段。
异常检测：单次操作级与轨迹级。各类检测机制依据其评估证据的粒度不同而划分为不同类别。单次操作级检测器会对每一次工具调用进行独立分类，并依据预先学习或指定的风险定义进行判定：输入与输出防护栏即属于此类机制；而 AgentMonitor（Naihin, 2023）则提供一种轻量级的"记录即标记"（log-and-flag）实现方案。此类检测机制成本低廉且易于审计，但无法识别那些将恶意行为分散至一系列看似无害的单次操作中的攻击手段------例如，那种以每分钟读取一个文件的极慢速度进行数据外泄的攻击。轨迹级检测器则会对一系列连续的操作序列进行整体性评估。AgentAuditor（Luo, 2025）将行为模式匹配技术与基于大语言模型（LLM）的推理能力相结合，对完整的操作轨迹进行分析。SentinelAgent（He, 2025）则将多智体之间的通信建模为一种时序图结构，从而能够标记出其中存在的异常交互模式。轨迹级检测能够捕获多步攻击，但其代价是引入了更高的延迟，且难以准确定位究竟是哪一具体动作触发了警报，从而使实时干预和事后解释工作变得更加复杂。在本文所调研的各类系统中，针对单一动作的检查通常采用"内联"（inline）方式部署，而轨迹级分析则通常通过异步方式对审计日志进行离线处理。
除了安全性考量之外，长期运行的智体（agents）还需要接受成本与资源的治理。
成本与资源审计。在涉及大量循环操作的工作负载中，一旦智体陷入"失控循环"（runaway loop），便可能迅速耗尽其API调用预算。2025年版《OWASP大型语言模型（LLM）十大安全风险》（OWASP Foundation, 2025）已将"资源耗尽"（Resource Drain）列为一个独立的风险类别。AutoHarness（AIMing Lab, 2026）系统能够追踪每一次API调用的Token消耗量，并通过其内置的"宪章"（constitution）机制，以声明式的方式强制执行会话级别的预算限制。在多智能体架构中，成本感知型治理尤为重要；在此类架构中，由于存在"扇出"（fan-out）模式，API调用的数量可能会呈指数级增长。
分层治理管道。一种新兴的设计模式将前述各类治理机制（包括针对具体任务的检查、钩子函数、宪章机制以及审计功能）整合进一条统一且可配置的管道之中。AutoHarness（AIMing Lab, 2026）系统便是这一设计模式的典型代表，它采用了三层式的治理架构。这三个层级逐层递进，实施着深度不断增加的检查：其检查范围涵盖了从基础的"解析---风险评估---权限校验---执行---审计"循环，到更高级的上下文丰富、输出内容校验、异常评分、人工介入升级以及形式化约束验证等一系列环节。用户可以通过YAML格式的"宪章"文件以声明式的方式选择所需的治理层级，从而确保治理工作的开销能够根据实际部署所面临的风险水平进行自适应调整。另有一些生产环境部署指南将上述各类职责抽象为"特性级"（feature-level）控制项，而非将其划分为明确命名的层级（Shavit et al., 2023）。究竟哪一种抽象方式在实际应用中更具可用性，目前仍是一个有待实证研究解答的开放性问题。
开放性挑战。在长期运行的智体系统中，审计日志的累积速度往往极快，由此引发了一系列关于存储空间、用户隐私以及"信噪比"（signal-to-noise ratio）方面的挑战。审计日志中可能包含敏感的用户数据、API密钥或具体的对话内容，这使得审计工作的完整性需求与数据保护法规的要求之间产生了某种张力。此外，当前业界尚缺乏统一且标准化的审计日志模式（schemas），这给跨系统的数据分析以及向监管机构提交合规报告等工作带来了诸多困难。
6 智体安全体系中的治理机制定位
治理机制的设立旨在应对并化解具体的安全威胁与风险。来自开放式智体间交互平台的近期证据（Zhang et al., 2026b; Kim et al., 2026; Chen et al., 2026; Wei et al., 2026）进一步表明，智体安全问题并非仅局限于提示注入或单智体越狱：社会工程、协同智体集群、凭据泄露以及平台层面的交互放大效应，均可共同塑造当前的威胁格局。Kim（2026）对128篇相关论文进行综述，并对智体技术栈各层面的51种攻击方法及60种防御方法进行了归类整理。Chen (2026) 从软件工程的视角对这一领域进行了补充，通过一套六维分类体系综合分析了 50 篇相关论文，并为"构建即安全"（secure-by-construction）的智能体平台提出了一套参考准则。利用这些框架，将治理机制与特定的安全风险相关联，并借此识别出潜在的覆盖盲点。
从设计维度到治理机制。Kim 确立七个设计维度（输入信任度、访问敏感度、工作流、动作、记忆、工具、用户界面），每个维度均代表着一个灵活性的光谱。灵活性的提升往往伴随着攻击面的扩大，而治理机制的作用正是在运行时对这种灵活性施加必要的约束。具体而言，权限模型用于界定工具与动作的边界；生命周期钩子（lifecycle hooks）在工作流中嵌入检查点；"宪章"（constitutions）将约束条件外化为显性规则；而审计基础设施则提供了一种反馈回路，用于揭示当前的约束设置是否过于宽松或过于严格。表 3 将各类治理机制与 Kim 分类体系中的七大风险类别（R1--R7）进行了对应映射。
现实世界智体中的防御空白。Kim针对六个智体系统（Codex、Gemini CLI、OpenHands、Browser Use、Nanobrowser、Skyvern）进行的案例研究揭示，没有任何一个智体能够全面实现所有的防御类别。在所有被调研的系统中，信息流控制、身份管理和形式化验证功能均处于缺失状态。在这六个案例中，监控机制均存在局限性：智体虽然会记录工具调用的日志，但却缺乏自动化的异常检测能力。AutoGPT的案例研究生动地展示这种缺陷所带来的后果：尽管可以通过下游补丁来解决个别表层症状，但上游的输入验证、信息流控制以及策略组合等关键环节却依然处于规范不足的状态。
纵深防御及其局限性。Kim指出，智体系统的安全性需要构建一套相互补充的分层防御体系：将输入防护栏作为第一道防线，输出防护栏作为最后一道防线；利用信息流控制与监控机制提供持续的运行时保护；通过访问控制机制实现身份认证与授权管理；并在涉及关键决策时引入"人在回路"（Human-in-the-loop）机制。然而，构建分层防御并非毫无代价；若各层防御机制之间缺乏协调，便可能产生相互干扰；此外，独立治理钩子（governance hooks）之间的可组合性目前仍未经过充分的验证。在此框架下，治理机制可充当"编排层"的角色，旨在协调各类防御机制协同工作，从而避免相互冲突。
作为拟议扩展的"上下文安全性"。Kim（2026）提出将"上下文安全性"（Contextual Security）作为智体系统继传统的"保密性---完整性---可用性"（CIA）三元组之后的第四个安全目标候选。这一提议尚属近期产物，且主要针对其调研范围内的特定情境；目前尚未获得美国国家标准与技术研究院（NIST）等标准制定机构的采纳，也未被主流的安全教材所收录。Conseca（Tsai & Bagdasarian, 2025）和CaMeL（Debenedetti et al., 2025）这两个项目案例，生动地展示了该领域的工程实践方向：即必须将"上下文"（Context）视为一种受控状态（governed state），而绝非仅仅是作为被动输入的"提示材料"（prompt material）。至于上下文安全性是否应当被提升至与CIA三元组并列的独立安全目标地位，目前仍是一个尚待定论的问题。
7 研究方向
表4总结各类系统的治理现状。
横切关注点。
层间交互模式。这七个层级并非相互独立。执行环境（E）制约着哪些生命周期与编排策略（L）是切实可行的；上下文管理（C）影响着评估结果的可复现性（V）；而治理（G）则施加了跨越所有其他层级的身份、权限及审计约束。因此，在审视框架设计时，应将其视为一种依赖关系结构，而非一份由相互独立组件构成的清单。
成本---质量---速度的三难困境。若要实现更强健的评估（V）、更严格的治理（G）、更丰富的可观测性（O）以及更逼真的执行环境（E），通常意味着成本的增加与延迟的提升。若优先追求速度，往往会牺牲诊断的深度或安全裕度；而若优先追求质量，则可能导致迭代成本过高，难以适用于常规的日常应用场景。在构建实际系统时，必须审慎抉择：哪些检查必须以同步方式执行？哪些可以离线运行？以及，面对何种类型的故障，才值得投入高昂的成本去启动恢复流程？
标准化与生态系统动态。诸如 MCP、ACP 和 A2A 等协议的出现，反映出一种旨在为工具、智体及编排状态构建共享接口的趋势。这种趋势使得"与具体智体无关的基础设施"较之"针对单一智体的集成方案"更具优势；但与此同时，这也将相应的责任转移到了治理与可观测性这两个层级之上：只有当框架的整体环境能够跨越不同的系统边界，完整地保留并传递溯源信息、权限状态、成本数据及故障证据时，标准化的工具调用才真正具有实际价值。
生态系统中持续存在的鸿沟。纵观整个研究语料，在各层级的边界处反复出现了五类显著的鸿沟：跨工具间的互操作性、成本归因、故障恢复、跨代码仓库的编排管理，以及人与智体之间的任务交接。
跨层综合。
1 成本-质量-速度三难困境
Harness 的可靠性受制于成本、质量和速度这三者之间的权衡取舍。更强的沙箱隔离机制和更逼真的运行环境虽然能提升安全性与可复现性，但同时也增加了启动延迟和基础设施成本；更丰富的上下文信息和记忆管理策略有助于提升任务的连续性，却会消耗 Token 资源并引入检索开销；更深入的评估与可观测性手段虽有助于故障诊断，却会拖慢迭代速度，并增加存储、标注及追踪数据处理的成本。因此，生产系统不能将"质量"视为一个单一的标量目标。系统必须审慎决策：哪些风险值得投入高昂的控制手段去防范？哪些检查可以采用异步方式运行或纳入回归测试套件？以及在智体（Agent）生命周期的各个阶段，哪些遥测数据值得被采集记录？
2 能力与控制的权衡
功能越强大的 Harness，赋予智体的权限也就越大；然而，权限的每一次提升，都会随之扩大"控制难题"的范畴。更丰富的工具集虽然拓宽了任务的覆盖范围，但也增加了工具选择出错的概率以及遭受"提示注入"（Prompt Injection）攻击的风险敞口；持久化内存机制虽有助于支持长期运行的任务，却也带来了数据溯源、数据陈旧以及隐私泄露等风险；而宽松的沙箱环境虽然使得智体的自主执行变得切实可行，但也放大了因行为失调或遭受攻击而引发的"破坏半径"（Blast Radius）。因此，"能力与控制的权衡"绝非仅仅是为一套原本功能完备的系统所添加的某种安全"附加组件"。相反，它是一条贯穿始终的设计主轴，将工具模式、上下文策略、运行时权限、身份认证、审计能力以及人工审批等各个环节紧密地联结在一起。
3 Harness 耦合问题
Harness 的各个层级之间存在着紧密的耦合关系，这使得任何局部的优化尝试都显得极其脆弱且极易失效。执行环境的差异会通过影响软件包的可用性、重置语义、系统延迟以及故障模式等因素，进而改变评估结果；工具的描述信息不仅会消耗上下文预算，还会反过来塑造模型（智体）的行为模式；只有当身份信息与权限状态被以相同的粒度进行采集时，可观测性追踪数据才具备作为治理依据的有效性；此外，评估机制的设计也会通过奖励某些故障恢复循环、惩罚另一些恢复循环的方式，反向作用并影响到整个系统的编排策略。这些层级间的耦合关系意味着：针对 Harness 所做的任何变更，都必须将其视为针对整个系统所做的变更，并以此为标准进行全面的测试与验证。单独来看，提示词、工具、记忆模块、沙盒、验证器或监视器似乎都颇具裨益；然而，一旦将其与控制回路中的其余组件结合使用，却可能反而会降低整个部署过程的整体效果。这种"耦合问题"也解释了为何在未明确指定其所处的"控制器"环境之前，无法将智体（Agent）的评分纯粹归功于其背后的模型本身。在"闭环"的视角下，对上下文策略、工具架构、验证器或故障恢复回路所做的任何更改，都会改变该智体所处的控制器环境（CH），进而改变同一模型所表现出的可观测行为（Bölük, 2026b）。
4 从智体框架到智体平台
当前的生态系统正处于从"智体框架"向"智体平台"演进的转型期。框架主要负责封装智体、工具、记忆存储及执行回路等局部抽象组件；而平台在此基础上，进一步增添了跨多次运行及多位用户场景下的持久化工作空间、受管沙盒环境、身份认证、计费管理、可观测性、性能评估、治理策略以及人机协作（人工接管）等功能。这一转型至关重要，因为那些需要长期运行的智体，已不再仅仅是单纯调用模型的程序；它们已演变为一套完整的"运营级系统"，对多租户隔离、合规性、故障恢复、执行轨迹留存以及组织层面的所有权归属等方面提出了严格的要求。因此，核心的设计问题也随之发生了转变：不再是"我该如何构建一个智体？"，而是"我该如何运营一支智体集群，并确保其在漫长的运行周期中，所有的行为操作始终保持可追溯且可撤销的状态？"
5 开放性研究议程
综合上述分析，勾勒出一份以"智体驾驭"（Harnesses）作为自适应控制系统为核心的研究议程。该领域亟需建立一套基准测试体系，该体系应着重于调整线束层面的干预策略，而非仅仅局限于调整模型权重；需要开发基于执行轨迹（Trace-native）的方法，以便跨层级地精准归因故障成因；需要制定一套协议规范，用于在智体、工具、沙盒、评估器及人类操作者之间顺畅地移交状态与职责；此外，随着底层模型能力的不断提升，还需要开发相应的优化方法，以实现对智体驾驭架构的持续简化与精简。