企业部署的 Agent
从一个扩展到几十个后，真正难管的不是聊天窗口，而是谁创建了它、它能读什么数据、可以调用哪些工具、写入动作由谁批准、发生错误时如何停用。所谓
Agent Control
Plane，可以理解为管理这些“谁能做什么、何时停”的统一控制层。本文用客服工单只读分诊和写草稿审批作为贯穿案例，拆解架构、字段、决策顺序、测试和上线门槛，并附上一份可打印架构图及离线教学项目。
核心结论：先管身份和动作，再建控制台
一套可用的 Agent Control Plane，至少要有 Agent
登记册、受信任身份、策略决策、执行前工具网关、审批、审计追踪和停用开关。登记册告诉组织“有哪些
Agent、谁负责、当前版本是什么”；策略根据主体、动作、资源、环境和预算给出允许、拒绝或待批；工具网关在真正调用前再次校验；审计把决策、批准与执行结果连起来。控制台只是这些能力的操作界面。没有服务端强制执行，界面里写着“需要审批”也不能阻止模型直接调用有权限的工具。
Control Plane
和运行时各管什么
在云服务语境里，control plane
往往负责配置、创建、修改和监测资源，data plane 承担实际请求与运行。AWS
的 Bedrock AgentCore Control Plane API
文档明确描述了配置、创建、修改、监测资源；其 Gateway、Identity、Policy
和 Observability 文档分别提供相关能力。微软关于 Agent
安全的官方指南也将登记、身份、最小权限与可观测放在治理框架中。本文将这些思想抽象成跨平台的设计建议，不意味着两个厂商的功能、可用区域和接口相同。
企业自己的控制面不必从零重造所有组件。现有身份平台可负责认证，API
网关可限制工具访问，审批系统可承载业务确认，日志平台可收集审计。Control
Plane
要解决的是统一清单、统一规则、统一证据和统一停止能力，并明确各系统之间的契约。先画清现有系统及缺口，再决定用供应商平台、组织已有服务或自建薄层组合。
核心功能拆解：七个必须回答的问题
| 能力 | 最小字段或机制 | 验收问题 |
|---|---|---|
| Agent 登记 | ID、所有者、用途、环境、版本、状态 | 能否找到无人认领或过期 Agent？ |
| 身份与授权 | 调用者、服务身份、租户、资源范围 | 模型自报身份能否被服务端拒绝？ |
| 策略决策 | 主体、工具、动作、资源、预算、版本 | 未知工具是否默认拒绝？ |
| 人工审批 | 请求 ID、参数、批准人、期限、状态 | 请求者能否自批或重复使用批准？ |
| 工具网关 | 执行前复核、超时、幂等、限流 | 停用后在途请求怎样处理？ |
| 审计与追踪 | 决策 ID、工具调用 ID、结果、时间 | 能否从业务结果回溯决策与版本？ |
| 停用与回滚 | Agent、工具、策略版本的开关 | 异常时多久切回人工流程？ |
登记是治理的入口。没有所有者和版本，安全团队无法判断谁批准过权限变化，运维也不知道故障要通知谁。策略决策与工具执行应分开：策略服务返回决定，网关实际阻断。审批同样只是授权条件之一，不能把“审批已通过”写成“工具已执行”。审计应记录决策、审批和真实执行三个不同事件，避免在事故复盘时把草稿当成已完成的业务动作。
从一条客服请求设计数据与状态
假设客服 Agent
需要读取已授权工单，按政策写一份回复草稿。它不能自动对外发送，更不能退款。登记记录为
support-triage，所有者是客服负责人，版本为
1.0，允许 read_ticket 和
write_draft
两种工具。请求带上受信任网关确认的调用者身份、规范化的工单资源
ID、估算成本和关联追踪 ID。策略首先检查 Agent
是否启用，然后核对工具白名单、资源所属范围和预算。读请求可以进入只读执行；写草稿先产生
pending_approval，由另一名有权限的客服主管审核。
审批要绑定具体请求、资源和参数，还应限制有效期和使用次数。生产中若草稿内容或目标工单改变，旧批准不应继续适用。工具网关在执行时再次核对
Agent
状态、审批效力、权限、预算和幂等键，执行后返回工具结果并写入审计。任何一环不可用，对高风险动作采用默认拒绝或转人工。客户实际的身份和数据权限模型必须由组织确认，不能用提示词里的“我是主管”替代身份令牌。
登记册应该怎样建
先把 Agent 当成可管理的服务资产，而不是一条提示词。每条记录要有唯一
ID、业务目的、负责部门、业务所有者、技术维护人、运行环境、当前版本、创建与最近复核日期、数据类别、工具清单、成本上限和停用联系人。状态可定义为申请中、测试中、启用、暂停与退役，并写清由谁批准转换。没有所有者的
Agent
应被标为待处理，不能因为它在旧系统里还能运行就自动续期。工具目录还要记录每个工具的输入和输出字段、资源域、是否写入、是否外发、后果等级、超时和负责团队。
不要把登记册与实际权限分离成两份长期不一致的表。平台可以定期对照运行时部署、网关调用和登记记录，找出未登记但有流量的
Agent、登记为停用却仍发起调用的服务，以及长期没有使用但保留权限的账号。对齐结果交给所有者复核，删除或收紧权限要按组织的变更程序完成。登记表中只写凭据的秘密管理引用，不写令牌本身。
决策结果要比“允许或拒绝”更细
实际服务可返回
deny、allow_read、require_approval、allow_with_limits
等状态，并附策略 ID、版本、理由代码、有效期和追踪
ID。理由代码帮助客服或运维理解是工具不在白名单、资源不属于当前租户、预算耗尽，还是
Agent
已停用。对用户界面只显示必要解释，避免把内部策略细节暴露给不应看到的人。预算和速率是两类约束：预算控制累计成本，速率控制短时间负载；高并发下检查和扣减必须原子化。审批积压还会产生运营成本，因此应有超时自动失效与值班升级路径。
一个可执行的最小项目
配套项目的 08-src/control_plane.py 用 Python 标准库和
SQLite 演示登记、白名单、预算、审批、停用与哈希链接审计。进入目录后运行
python control_plane.py，会依次看到只读允许、写草稿待批、另一名演示审批人批准、停用后新请求被拒以及审计校验结果。运行
python -m unittest -v，八项测试覆盖只读允许、未知工具拒绝、越界资源拒绝、超预算、职责分离、停用、待批时停用和历史事件篡改检测。制作时八项测试全部通过。
这是一套离线状态机，不调用真实模型、工单系统或 MCP Server。示例中的
actor 与 approver
是普通字符串，并没有认证；demo:
前缀只是演示资源规则。SQLite
哈希链能发现这份数据库中的部分改动，却不能防止有数据库完全控制权的人重写所有事件与哈希。因此不要把它当作生产身份系统或不可篡改审计。参考
n8n JSON 也只是未激活的结构骨架，其中指向的策略 HTTP
服务没有在示例中实现；目标实例导入和节点参数需另行验证。
从需求到上线的六步实施法
- 盘点和分级。 列出全部
Agent、业务所有者、数据域、工具、环境、版本与现有权限。按只读建议、内部写入、对外发送和资金或权限操作分层。先让一个低风险
Agent 进入试点。 - 定义策略契约。
为每个工具明确调用主体、动作、资源标识、允许范围、预算、超时和返回结果。策略采用默认拒绝；未知
Agent、工具或资源不能因为模型“解释得合理”而放行。 - 接入可信身份与网关。
由网关校验令牌和租户，不把身份从自然语言中解析出来。工具执行前独立复核，限制网络出口、并发与重试。跨租户资源
ID 做规范化，避免前缀拼接造成权限绕过。 - 加入审批与审计。
写动作区分请求、批准和执行。请求者不能自批；批准绑定资源、参数、期限和单次使用。记录策略版本和
request_id，日志独立存储，敏感内容脱敏。 - 用失败场景评测。
测未知工具、跨租户资源、重复审批、并发预算、服务故障、日志故障、提示注入、停用后在途请求。业务、安全、数据、运维分别确认阻断条件。 - 灰度、停用与回滚。
从只读流量开始，写操作继续人工批准。设异常率、成本、审批积压和越权尝试告警，演练停用、人工接管和策略版本回滚。
实际工作流：一次写草稿申请
客服 Agent 收到工单 T-001，只读工具返回必要字段。模型可以建议“调用
write_draft”，但请求要先经过策略服务。服务发现该 Agent
已登记、工具在白名单内、资源属于已授权工单且预算未超，于是生成待批请求
ID。客服主管看到草稿内容、政策依据、目标工单与预计影响，批准或拒绝。批准后由工具网关重新校验状态和参数，调用草稿接口，记录真实结果。若
Agent
此时已停用，旧批准自动失效；若工单已被其他客服处理，幂等和状态校验避免重复写入。整个流程都应能由一个追踪
ID 串起来。
离线项目会演示待批、批准和停用，但不会执行真实写草稿接口。实践中尤其要区分
allowed_read、pending_approval、approved、executed、failed
与
cancelled，它们是不同事实。一个漂亮的控制台如果只显示“成功”，却无法判断究竟是决策成功还是工具成功，对运维没有帮助。
平台选型：买现成能力还是自建薄层
大型云平台已有部分登记、身份、网关、策略和可观测能力，适合在其生态内统一治理，但跨云、多框架和既有企业系统的连接方式需要逐项验证。自建薄层可以统一不同运行时的登记、策略字段和审计格式，不过身份、审批一致性、可靠性和运维成本不能省略。比较时用同一张能力表试验：能否从登记定位所有者；能否拒绝跨租户工具调用；审批能否绑定参数且防重放；停用后是否阻断新旧请求；审计能否关联真实执行；模型和平台费用能否分开统计。
选型评估最好准备一组相同的演示 Agent
与测试请求，在候选平台上走完登记、策略变更、权限拒绝、审批、执行回执和停用，而不是只看产品页面的功能列表。记录部署版本、地域、身份集成、日志导出方式、数据留存选择和额外计费项。平台提供“审计”不一定意味着满足组织的留存和不可篡改要求；平台提供“审批”也不一定天然支持绑定参数、单次使用和职责分离。缺口可以由已有企业服务补足，但所有跨系统失败路径都要有所有者。
对于已有多个框架和供应商的企业，可以先统一最小字段与事件格式，暂不迁移全部
Agent
运行时。让每个运行时通过适配器上报登记、决策请求和执行结果，在网关处实施共同的最低权限规则。第二阶段再处理策略继承、成本归集、风险分级和自动发现。这样可以避免为了上线控制面先重写全部业务
Agent，同时也避免只收集日志却没有实际阻断能力。
免费资料《Control Plane
架构图》把这些关系压缩成一页，可在架构评审会上标出系统负责人和缺口。付费项目则提供离线源码、八项测试、三张工作表、配置与部署材料，适合按本教程做一轮可复核的练习：下载免费架构图；查看完整项目。两者是设计与教学材料，真实生产接入仍需组织自己的身份和工具网关验证。
风险、限制与运营责任
最容易被低估的是策略漂移：Agent
升级了提示词、模型或工具列表，登记版本却没更新。把配置变更与审批、评测和回滚联系起来；策略变更留差异、批准人和生效时间。另一项是“只读”造成的数据泄露：读取工具也可能返回跨租户、个人或机密资料。检索权限应在源系统和工具网关两处审查，并限制返回字段。模型收到的网页、文档和工单正文是低信任数据，不能提升为策略配置。
审计既不能太少，也不能无节制地记录原文。保留决策和执行所需的标识、版本、状态、时间与摘要；对敏感参数脱敏，按组织政策设置保存期限和访问审批。追踪字段可参照
OpenTelemetry 的生成式 AI
语义约定，但具体字段和稳定性需以目标版本文档核对。不要为了排障把密钥、完整个人数据或全部
Prompt
默认写入日志。哈希链不是独立不可篡改存储，生产环境还需要权限隔离、备份和事故保全。
停用开关要明确作用范围：只停一个
Agent、停某个危险工具，还是停全局入口。停用时新请求必须阻断；在途请求要么取消，要么隔离并按策略完成，不能放任未知状态。恢复不应只是把按钮打开，需确认事故原因、策略版本、未完成审批和客户通知。采购或自建选择还要考虑厂商功能、地域、接口、价格变化；本文不提供某平台的固定价格或可用性承诺。
上线后每月检查登记有效性、长期未使用权限、拒绝原因分布、审批耗时、人工修改率、工具错误率和实际费用。业务所有者负责确认
Agent
仍解决当前问题；安全团队复核高后果权限与异常访问；运维负责告警和停用演练；数据负责人关注来源、敏感字段和留存。将这些职责写入运行手册，避免事故发生后才争论谁可以按下停用开关。政策与模型并非一次配置永久有效，组织流程、人员和供应商接口变化都可能让旧的许可边界失效。
做季度复盘时，选择几条真实但已脱敏的历史请求，复现当时的 Agent
版本、策略版本与审批记录。若无法重建当时的决策依据，说明日志字段或版本归档仍有缺口。对错误拒绝与错误放行分别分析：前者影响业务效率，后者可能影响数据和资金安全；两者不应被合并成一个平均“成功率”。将改进项分配给具体负责人，写明完成日期，再用固定回归样本验证变化。
常见问题
Control Plane 一定要有独立产品吗？
不一定。组织已有的身份、网关、审批与日志服务可以组合，关键是统一登记、规则和证据，并确保执行层强制校验。
把工具列表写进系统提示词够吗？
不够。提示词有助于模型提出合规请求，真正的工具与资源权限必须由服务端检查。
审批通过是否表示工具已执行？
不表示。批准只是授权条件；执行前应重查身份、参数、状态与有效期，并记录实际成功或失败。
只读 Agent 是否可以省略审计？
不建议。读取也可能触及个人或跨租户资料，至少保留必要的访问与决策证据。
为什么要把 Agent 版本纳入登记？
模型、提示词、工具和知识源变化会影响结果。版本让评测与事故复盘有可追溯对象。
如何验证停用开关？
在隔离环境发起新请求与待批请求，确认它们按预设规则被拒绝，并演练人工接管和恢复流程。
事实依据与来源
- AWS
AgentCore Control Plane API：配置、创建、修改与监测资源。 - AWS
AgentCore 安全实践：最小权限、身份、网关、审计等机制。 - Microsoft
Agent 安全指南：登记、身份、最小权限和可观测治理。 - NIST
AI RMF 生成式 AI Profile：生命周期风险管理参考。
站内延伸：企业到底需要哪些
AI Agent？10 个真实场景；AI Agent
项目怎么报价？。
内容核验日期：2026-10-07。厂商文档支持相应产品事实；统一控制面架构与离线项目属于本站设计建议，未在客户生产环境验证。
工程附录：执行网关与验收
以下合并原 Control Plane 完整项目中的工程示例，作为上文最小项目的进一步实现参考。
FastAPI 执行网关核心示例
下面展示控制顺序，省略具体 JWT、SPIFFE 和数据库实现。生产代码必须使用经过审查的库，并把关键检查放到独立服务或中间件中。
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import Any
app = FastAPI()
class ToolRequest(BaseModel):
tool: str
resource: str
environment: str
arguments: dict[str, Any]
idempotency_key: str
@app.post("/v1/tool-calls")
async def call_tool(req: ToolRequest):
auth = await verify_user_and_workload_identity()
normalized = normalize_and_classify(req, auth)
kill = await kill_switch.snapshot(normalized)
if kill.active:
await audit.denied(normalized, reason="kill_switch", snapshot=kill)
raise HTTPException(423, "Execution disabled by control plane")
decision = await policy.evaluate(normalized, kill)
if decision.effect == "deny":
await audit.denied(normalized, reason=decision.reason)
raise HTTPException(403, "Policy denied")
if decision.effect == "require_approval":
grant = await approvals.require_valid_grant(normalized, decision)
if not grant:
return {"status": "pending_approval", "request_id": normalized.id}
lease = await credentials.issue_scoped_lease(normalized, decision)
try:
result = await executor.run(normalized, lease, timeout_seconds=30)
safe_result = filter_tool_result(result)
await audit.completed(normalized, decision, safe_result.metadata)
return {"status": "completed", "result": safe_result.content}
finally:
await credentials.revoke(lease.id)
异常处理要区分“未执行”“执行成功但响应超时”“部分执行”和“未知状态”。对写操作，客户端重试前先用幂等键查询状态；不能因为 HTTP 超时就直接重放。长任务需要独立 Task ID、每次轮询鉴权、取消权限和终态审计。
[/aistack_login_gate]
策略、审批与熔断的数据模型
最小数据库可以包含：principals、agents、workload_identities、tools、resources、policy_bundles、policy_decisions、approval_requests、approval_grants、kill_switches、credential_leases、tool_executions 与 audit_events。
关键约束包括：Approval Grant 的 request_hash 唯一绑定，uses 不得超过 max_uses；Tool Execution 必须引用 Decision；Decision 必须记录 policy digest；Kill Switch 使用乐观锁版本；审计事件只追加不覆盖。删除个人数据时，可使用分离的加密内容仓与密钥销毁实现合规删除，同时保留最小事件证据。
多租户系统必须把 tenant_id 作为所有主键或行级安全条件的一部分，不能只靠前端过滤。任何跨租户支持操作都需要专用角色、工单引用、时间限制和额外审计。
安全测试与验收矩阵
| 测试类型 | 场景 | 预期结果 |
|---|---|---|
| 身份 | 用户 Token audience 错误、工作负载凭据过期 | 调用在策略前被拒绝 |
| 委派 | 子 Agent 超过最大深度或提升 scope | 拒绝并记录完整委派链 |
| 策略 | PDP 超时、策略包签名错误 | 高风险 fail-closed |
| 审批 | 参数在审批后变化、Grant 重放 | 请求哈希不匹配或次数耗尽而拒绝 |
| Kill Switch | 执行前与排队中激活工具级熔断 | 新调用拒绝，队列取消，凭据撤销 |
| 审计 | 日志后端暂时不可用 | 按风险缓冲或拒绝，不静默丢失 |
| 重试 | 工具已成功但网关超时 | 幂等查询返回原结果，不重复写入 |
| Prompt Injection | 工具结果要求绕过策略 | 内容被标记，执行路径仍需策略决策 |
| 隐私 | 提示词包含密钥和个人信息 | 审计只保存脱敏摘要与引用 |
| 越权 | Agent 直接访问目标系统绕过 Gateway | 网络策略与资源端鉴权阻断 |
真正的验收重点是“是否存在绕行路径”。如果 Agent Pod 能直接访问数据库、云 API 或 MCP Server，Control Plane 即使决策正确也只是旁路观察。应通过网络策略、服务网格、私有 DNS、凭据 Broker 和资源端 audience 校验，确保受管工具只能接受 Gateway 身份。
成本、性能与高可用设计
成本主要来自三部分：控制服务与数据库基础设施、遥测与审计存储、人工审批带来的等待时间。模型 Token 往往不是 Control Plane 的主要成本，但策略输入、工具结果和审计若无大小限制，会同时推高 Token 与日志费用。
低延迟路径可把签名策略包和 Kill Switch 状态缓存在 Gateway 本地，将只读低风险决策控制在一次本地评估；高风险动作可以接受额外网络请求和审批等待。策略缓存必须携带版本和过期时间，紧急熔断使用推送通道更新。不要无限缓存 allow 结果，因为主体、资源和风险状态会变化。
Control API、PDP、审批服务和审计管道应独立扩容。PostgreSQL 使用高可用与定期恢复演练；Redis 不作为唯一事实源；审计事件先写耐久队列再异步索引。Kill Switch 状态需要多副本和明确冲突规则，通常以更严格状态优先。
上线前定义 SLO：策略决策延迟、审批通知延迟、审计完整率、熔断传播时间、凭据撤销时间和未知状态任务比例。本文不提供虚构的通用毫秒指标，企业应根据区域、工具风险和业务连续性要求压测确定。
迁移路径与回滚方案
建议分四阶段迁移：
- Observe： 只接入身份映射和审计，不阻断，但识别所有工具、凭据和绕行路径。
- Recommend： Policy 产生影子决策，与现有结果对比，修正误报和缺失上下文。
- Enforce High Risk： 先强制高风险写操作、生产环境和敏感数据，接入审批与 Kill Switch。
- Default Deny： 所有工具通过 Gateway，采用显式 allow，逐步关闭直连凭据和旧网络路径。
每阶段都要保留回滚：策略包可回退到上一个签名版本；Gateway 可切换到经过批准的保守策略；审批服务异常时高风险操作暂停；审计后端故障时使用本地加密缓冲；Control Plane 故障不能导致 Agent 获得更大权限。
不要用“临时关闭鉴权”作为恢复手段。业务连续性模式也应是预先定义、范围有限、自动过期并可审计的 break-glass 策略，且通常需要双人授权。
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
