构建受控的 AI Agent：Agent 支架 (Agentic Scaffolding) 实践指南

大多数构建 AI Agent 的团队在第一个月都在追求性能：更好的提示词、更智能的路由、更快的检索。接下来的六个月，你则会忙于补救之前忽略的东西——治理（governance）。无法被审计的 Agent 会被法务部门叫停。没有权限边界的 Agent 会在预发布环境中造成混乱。没有人工升级路径的 Agent 则会在规模化运行时悄无声息地犯下严重的后续错误。

一个令人不安的事实是，大多数 Agent 部署之所以失败，并不是因为模型性能不足，而是因为围绕它的脚手架（scaffolding）缺乏结构。近三分之二的企业正在尝试 Agent；但只有不到四分之一的企业成功实现了生产规模化。差距不在于模型质量，而在于治理。

什么是 Agent 架构脚手架？

在 Agent 的语境中，“脚手架”一词是指围绕 LLM 构建的所有内容，旨在将其从一个文本预测器转化为一个目标驱动的系统：内存层、工具调度逻辑、重试和回退处理、专家间的路由，以及最关键的——护栏（guardrails）、权限和审计机制。

一个有用的思维模型是将脚手架视为三个不同的层：

• 执行层 —— LLM 调用、工具调用和动作序列
• 协调层 —— 路由、交付、状态管理、多 Agent 编排
• 治理层 —— 护栏、权限、人工升级和审计追踪

大多数开发者在头两层投入巨资，而将第三层作为事后补充。到那时，治理层往往在与已经定型的架构决策作斗争。成功的团队从一开始就会将这三层作为一个整体进行设计。

Agent 治理的三大支柱

在调查了金融服务、医疗保健和企业软件领域的生产部署后，一个一致的三大支柱框架浮出水面：护栏、权限和可审计性。每一项都针对一种特定的失败模式。

支柱 1：护栏 (Guardrails)

护栏是防止 Agent 超出授权范围行动的行为约束。最原始的实现是在输出阶段进行单一的安全性检查——在展示 Agent 的言论之前对其进行检查。这对于执行动作的 Agent 来说是远远不够的。

更稳健的模式是在每一个决策边界设置分层护栏：

• 预检护栏 (Pre-flight guardrails) 在 LLM 调用前运行。它们拦截明显的滥用：用户输入中的 PII（个人身份信息）、提示词注入尝试、以及超出 Agent 定义范围的请求。这些检查速度快且成本低。
• 步骤级护栏 (Step-level guardrails) 在每次工具调用时运行，而不仅仅是在最终响应时。执行多步工作流（搜索数据库、起草文档、发送通知）的 Agent 需要在每个动作处进行安全检查。链路中间产生的恶意工具输出可能会劫持下游的所有环节。
• 响应后护栏 (Post-response guardrails) 在 LLM 生成输出后、交付前运行。它们处理特定的输出风险：响应中的敏感数据、事实幻觉、范围蔓延。

分层至关重要，因为没有哪一个护栏层能拦截所有问题。LLM 具有随机性——即使一个护栏能正确拦截 99.9% 的问题输入，在足够的规模下，它仍然会放行有害内容。深度防御是唯一在架构上可靠的方法。

一个实用的模式：将护栏逻辑编码为“策略即代码”（policy-as-code），并与你的应用程序一起进行版本控制。这使得治理在正常的 CI/CD 流水线中是可审计、可测试且可部署的。未通过的偏见检查或未记录的模型更改可以阻止合并并触发告警，而不是在生产环境中暴露问题。

支柱 2：权限与最小特权 (Permissions and Least Privilege)

传统的最小特权模型——列举用户可以做什么，拒绝其他所有操作——无法直接套用到 Agent 上。人类在遵循工作流时会在执行前审查每个动作。而 Agent 可以在几秒钟内串联起几十个操作，从而放大了任何过宽权限的“爆炸半径”。

失败模式是可预见的：一个范围限定在“客户支持”的 Agent 最终访问了计费系统，因为其运行所使用的服务账号保留了之前项目留下的广泛读取权限。没人故意这样做，只是它没有受到约束。

正在兴起的方法是基于运行时、有时间限制的权限：

• 访问范围按任务而非身份设定。与其授予 Agent 长期权限，不如生成仅授权当前任务所需特定动作的短期 Token。
• 权限在任务结束时自动过期。攻击者没有持久会话可以劫持。
• 风险级别动态调整权限。常规查询获得窄访问权限。超过阈值的财务交易则需要必须显式授予的提升权限。

Okta 的 2025 年基准测试显示，当从 24 小时会话 Token 切换到 300 秒任务范围 Token 时，凭据窃取事件减少了 92%。安全性的提升几乎完全源于缩短了暴露窗口，而不是源于更复杂的身份验证。

对于使用模型上下文协议（MCP）或类似工具框架的 Agent，AI 网关模式正变得越来越实用：每一次工具调用都会经过一个策略执行点，该点在执行前根据当前权限验证请求。Agent 永远不会直接触及基础设施——它请求能力，由网关决定是否授予。

支柱 3：可审计性

无法被审计的智能体（Agent）在生产环境中是无法获得信任的。这听起来显而易见，但智能体的审计日志与 API 的审计日志有着本质的不同。

传统的 API 日志记录输入和输出。而智能体的审计追踪需要捕捉完整的推理轨迹（reasoning trajectory）：智能体在做出决策时拥有哪些信息、它调用了哪些工具以及调用顺序如何、它经历了哪些中间状态，以及至关重要的一点——为什么它选择了这条路径而不是其他替代方案。如果没有这些，调试错误的智能体决策几乎是不可能的。

在你的身份管理系统中，每个 AI 智能体都应该拥有一个独特的非人类身份——不是一个共享的服务账户，而是一个拥有自己生命周期治理的唯一身份。这实现了归因：当出现问题时，你可以准确地追踪是哪个智能体在行动、拥有什么权限、由哪个用户发起，以及在什么时间。

结构化追踪是实现这一点的具体机制。将 LLM 调用、工具执行和任务移交分组在单个追踪上下文（trace context）下，并使用描述性的、可搜索的名称（例如，“Deal Screening - Healthcare - 2026-02-16”，而不是 “agent-run-4821”）。这使得过滤变得有意义，并能对不同运行中的故障模式进行系统性分析。

监管环境正在迎头赶上。SOC 2 信任服务标准（Trust Service Criteria）现在直接嵌入了 AI 治理要求。欧盟 AI 法案（EU AI Act）的核心要求将于 2026 年 8 月生效。ISO/IEC 42001 正在从可选指南转变为企业采购中的合同要求。如果你的智能体不能根据需要生成审计追踪，你就在累积合规债。

人机回环：何时暂停，何时继续

人机回环（Human-in-the-loop, HITL）并不是对智能体不够优秀的妥协——它是一种设计选择，旨在确定哪些决策具有足够的后果，从而需要人类判断的参与。

其模式是：为超过风险阈值的决策定义审批检查点，在这些检查点暂停执行，仅在人工审核后恢复。实现良好的 HITL 可以将复杂决策任务的智能体错误率降低多达 60%，同时允许高容量、低风险的操作完全自主执行。

最难的部分不是机制，而是定义阈值。一个有用的启发式方法是：按可逆性和爆炸半径（blast radius）对操作进行分类。查询数据库是完全可逆的且没有爆炸半径——不需要审批。向客户发送电子邮件是不可逆的，并且具有声誉爆炸半径——考虑设置审核步骤。删除记录或发起金融交易是不可逆的，且具有潜在巨大的爆炸半径——必须要求显式审批。

像 LangGraph 这样的框架通过 interrupt() 函数使这一点变得具体，该函数会在执行中途暂停并将控制权交给人工审核员。智能体状态被序列化，发送审核请求（通过 Slack、电子邮件或审核仪表板），并以人类的决策作为输入恢复执行。智能体永远不会丢失上下文；人工审核员可以确切地看到智能体正准备做什么以及为什么要这样做。

一个实际的反模式：将每个边缘案例都路由到人工审核。永远处理不完的审批队列会训练人们不经阅读就批准，这比没有审批更糟糕。设计 HITL 以处理现实的任务量——如果你的估计表明每天有 200 次审核，那么请构建一个人类实际上可以在合理时间内完成的工作流。

真实的失败及其揭示的问题

在事后分析中，有两类生产环境失败经常出现：

**行为故障（Behavioral failures）**是大多数人想到的——智能体做了错误的事情。麦当劳的 AI 驱动器点了 260 份鸡块；谷歌的 AI 建议在披萨上加胶水。这些都会被媒体报道。其根本原因通常是缺失护栏（guardrails）或范围约束不足。

**协作故障（Coordination failures）**更危险，因为它们隐藏得更久。在多智能体系统中，智能体之间的通信故障会导致重复操作、任务丢失和工作流不完整。一项 2025 年的分析指出，协作故障是企业级多智能体部署中的主要失败模式。其中一起事件需要开发者花费 200 多个小时进行审计和纠正，因为当时不存在追踪基础设施来重建发生过的事情。

这两类问题的共同点是：团队构建速度很快，随后发现他们跳过的治理基础设施其实是核心支撑。

治理是一门技术学科

成功落地生产级智能体的团队将治理视为一个工程问题，而不是一个合规性复选框。这意味着：

• 护栏覆盖率是经过测量的，而不是假设的。就像测试覆盖率一样，你应该知道百分之几的智能体操作类型通过了哪些护栏层。盲点被视为技术债务进行跟踪。
• 权限在拉取请求（PR）中进行审查。智能体权限的范围变更需要经过代码审查，就像数据库模式迁移一样。
• HITL 阈值是根据经验调整的。审查误报率（触发了人工审核但其实不需要的操作）和漏报率（没有触发审核但其实应该触发的操作）。根据观察到的事件调整阈值。
• 审计日志是用来查询的，而不仅仅是存储。一个你从不查询的审计追踪只是形式主义。构建仪表板和告警来发现异常：智能体在通常范围之外的操作、异常的延迟峰值、高频率的护栏触发。

切入点很重要：治理并不会减慢你的速度。被法务部门关停的未经治理的智能体，或者导致需要法证调查的事故，才会减慢你的速度。提前构建治理基础设施是通往可持续生产部署的更快路径。

2026 年的生产级技术栈

2026 年出现的生产级智能体技术栈呈现出一致的形态：

• 一个路由层，负责对请求进行分流，并将其委派给具有明确能力范围的专业智能体
• 专业智能体，具有精简的指令以及与其功能相匹配的工具访问权限
• 一个介于智能体与基础设施之间的 AI 网关，以策略即代码（policy-as-code）的形式强制执行权限
• 在预检、步骤级和响应后阶段设置的分层护栏
• 在定义的风险阈值处触发的 HITL（人机回环）工作流，其审核队列根据人力容量进行调整
• 结构化追踪，通过唯一的智能体标识捕捉完整的推理轨迹
• 基于追踪基础设施生成的合规报告，而非作为一个独立的系统

这些组件都不罕见。大多数可以利用现有的开源库和云基础原语构建。挑战在于从一开始就将它们连贯地集成在一起，而不是在之后将治理层强行补建到并非为此设计的智能体架构中。

如果你今天正在启动一个新的智能体项目：请在构建能力层之前先构建治理层。在设计阶段就定义好你的权限模型、审计架构和 HITL 阈值。LLM 提示词和工具实现可以不断演进。但为一个已经运行了数月的生产系统补建审计追踪是非常痛苦的，这种痛苦程度远非提示词工程可比。

那些能在 2026 年实现持续生产级运行的智能体系统，将是那些把治理视为一级工程关注点的系统——治理不是障碍，而是实现自信部署的基础设施。