AI智能体生产落地：OCE开源自托管凭证与审计实践

AI 智能体这个东西，Demo 阶段和上线阶段完全是两码事。我见过太多团队花两周搭出一个能自动查数据、自动发工单、自动改配置的 Agent，演示的时候全场鼓掌，等到要放进生产环境，安全那边只问三个问题就卡住了：这个 Agent 用谁的账号在操作？它能碰哪些东西、碰不了哪些东西？出了问题，日志在哪、责任怎么算？这三个问题答不上来，再炫的能力也只能躺在测试环境里。OpenClaw 企业版 OCE 这次放出来的东西，核心就冲着这三问去的——开源、免费、可自托管，把 AI 智能体从"临时工"变成"持证上岗"的角色：有唯一身份、有签发出来的凭证、有明确的作用域和有效期、有可回放的审计轨迹。如果你正在做企业内部的 Agent 平台，或者你是那个被拉去评估"这东西能不能上生产"的平台工程师、安全合规同学，这篇可以当作一份落地前的可行性笔记来看。我把架构拆解、自托管部署、凭证与策略配置、还有我自己踩过的坑，尽量写成可以直接抄作业的程度。

1. 先搞清楚"持证上岗"到底解决什么问题

1.1 智能体上生产的三道坎：身份真空、权限失控、责任不可追溯

大多数团队做 Agent 的第一版，都是把模型 API Key 直接写进环境变量，工具调用用一把管理员级别的长期密钥打通所有系统。这套东西在 Demo 里跑得飞快，因为它绕过了所有繁琐环节。但一进生产，问题就成串冒出来。

第一道坎是身份真空。Agent 在系统里没有独立身份，它要么借用某个人的账号，要么借用一把服务账号的万能钥匙。前者意味着 Agent 干的所有事都记在那个人头上，那个人休假了 Agent 也跟着停摆；后者意味着一旦密钥泄漏，你连是哪个 Agent、哪次调用泄漏的都说不清。第二道坎是权限失控，Agent 天然需要调用一堆工具，查库、发消息、改工单、跑脚本，如果不做边界，它拿到的权限往往等于"整个运维组"。第三道坎是责任不可追溯，模型输出是非确定性的，同一个输入两次结果可能不一样，如果调用链、工具入参、策略命中情况没有完整留痕，事后复盘基本靠猜。

OCE 的思路是把这三件事合成一个动作：给每个 Agent 发一张"证"。这张证不是比喻，是实打实的凭证对象，带着主体标识、作用域、有效期和签发来源。有了它，权限收敛、审计追踪、故障定位才有抓手。

1.2 一张"证"里必须有的四个要素

我在评估任何 Agent 治理方案时，都会拿这四个要素去对：标识、凭证、作用域、有效期。少一个，这套体系就是漏的。

标识是 Agent 的唯一 ID，并且要求全局唯一、不可复用。这一点经常被忽略——很多团队用"Agent 名称"当标识，结果两个团队都叫"运维助手"，日志混在一起。凭证是这个身份的证明载体，通常是短时效的签名令牌，配合双向证书做通道认证。作用域决定了这张证能开哪些门，粒度要细到"工具 + 操作 + 资源范围"三级，比如"只允许读取 A 项目的告警记录，不允许写入"。有效期是最容易被跳过的一环，长期有效的凭证等于没有凭证，一旦泄漏就是永久后门。

把这四个要素落到位，Agent 就从"某个脚本"变成了"系统里的一个可管理主体"。这个转变带来的直接好处是：你可以像管理员工账号一样管理它——入职签发、调岗改权限、离职吊销。

1.3 开源、免费、自托管：这个组合背后的取舍

看到"开源免费"，很多人的第一反应是"那肯定有坑"。我倒觉得这个组合在企业场景里是有明确逻辑的。Agent 平台最敏感的东西不是代码，是数据流向和调用记录——Agent 读了什么、问了什么、把什么发给了模型，这些本身就构成企业的高敏信息。如果这套东西跑在别人的机房里，安全评审那一关很难过。自托管把数据边界重新拉回企业内网，这是很多方案被否掉的第一原因，OCE 直接把这个门槛拿掉了。

代价当然也有。自托管意味着你要自己扛部署、升级、备份、容量规划，还要自己处理模型接入的稳定性和成本。免费不等于零成本，运维人力是实打实的支出。我的建议是把它当成"基础设施组件"而不是"开箱即用的 SaaS"来规划，先算清楚需要几个人维护、多久升一次版本，再决定要不要上。

提示：自托管方案在评估阶段最容易低估的是"升级成本"。策略格式、凭证格式这类核心结构一旦在版本间发生不兼容变更，回滚会很痛苦。上线前务必确认版本升级的兼容性策略。

2. OCE 的整体架构：控制面、执行面、观测面三层拆开看

2.1 控制面负责"发证"和"定规矩"

控制面是整个体系的大脑，干三件事：Agent 注册、策略下发、凭证签发。Agent 注册时提交一份清单，声明自己叫什么、属于哪个业务域、需要调用哪些工具、预期调用频次。清单审核通过后，控制面把它写进注册表，同时生成对应的身份记录。

策略下发是控制面里最容易做复杂的一块。我倾向的做法是策略与 Agent 解耦——策略按"业务域 + 环境"组织，Agent 只引用策略集的名字。这样新增一个 Agent 时不用重新写一遍权限，直接继承所在域的基线策略即可。凭证签发则是按需的、短时效的，Agent 启动时用自己的引导凭证去换一张工作凭证，工作凭证默认 15 分钟过期，过期前自动续期。这个设计的意义在于：即使工作凭证被截获，攻击窗口也只有十几分钟。

控制面本身要做高可用。我的经验是最少两个实例挂在一个内部负载均衡后面，背后的注册数据用主从库，策略变更走版本号机制，避免多实例之间读到不一致的配置。

2.2 执行面才是真正"干活"的地方

执行面包含运行时沙箱和工具网关两块。沙箱是 Agent 进程实际跑的地方，我强烈建议默认配置成：根文件系统只读、独立的临时目录、禁用特权、系统调用白名单收窄。这些限制会让某些"顺手就能干"的操作变麻烦，但正是这些麻烦挡住了大部分事故。

工具网关是 Agent 访问外部系统的唯一出口。所有工具调用都必须过网关，网关拿到请求后做三件事：校验凭证是否有效、比对策略是否放行、记录完整调用日志。这个"唯一出口"的约束是整套体系能成立的前提——只要有一条绕过网关的路径，审计就不完整，整套治理就退化成摆设。实操中这一条最容易破功的地方是：某位同学为了调试方便，直接在沙箱里配了一个出口直连内部服务。所以网络策略必须从基础设施层做硬隔离，不依赖 Agent 自觉。

工具网关上还可以挂一层参数级的检查。比如"发消息"这个工具，可以限制收件人必须在白名单域内；"执行脚本"这类高危工具可以强制要求人工确认。这层检查不替代策略，它处理的是"策略放行了但内容有问题"的情况。

2.3 观测面：没有日志的治理等于没有治理

观测面常被当成附属品，实际上它是整套体系的价值出口。我在设计日志字段时坚持三样东西必须齐：谁调的、调了什么、决策依据是什么。具体到字段，至少要有 trace 标识、Agent 标识、凭证标识、工具名、参数摘要、策略命中结果、耗时、token 消耗、策略版本号。

参数摘要这里有个细节：不要记原始参数，记哈希加脱敏摘要。原因很直接，工具参数里经常混着手机号、身份证、内部地址这类信息，日志库一旦被翻出来就是二次泄漏。哈希用于比对"两次调用是不是同一个输入"，摘要用于人工排查时能大致看懂在干什么，原始值不该落盘。

再补一句成本相关的：观测面顺手把 token 消耗按 Agent、按业务域聚合起来，月底对账的时候你会感谢自己。我见过一家公司上线两个月才发现某个 Agent 因为提示词写得太啰嗦，单日消耗是同类的六倍。

2.4 三种部署形态怎么选

自托管不等于只有一种玩法。根据团队规模和安全要求，常见的三种形态差别挺大：

我一般建议从单机一体化起步，把 Agent 数量控制在五个以内，先跑通"发证—调用—审计"这条主链路。等业务流程验证有价值了，再把执行面拆出去。一上来就搞三环境分离，很容易在证书和网络策略上耗掉两周，最后业务方失去耐心。

3. 自托管实操：从零把这套东西跑起来

3.1 环境准备与资源估算，先算账再动手

动手之前先把资源账算清楚，这比装软件重要。以一个中等规模试点为例：10 个常驻 Agent，每个平均 2 路并发，工作时段 8 小时，平均每小时 30 次工具调用。日调用量大约是 10 × 2 × 30 × 8 ≈ 4800 次。这个量级下，控制面给 2 核 4G 完全够，工具网关 4 核 8G（网关是同步阻塞型，CPU 主要消耗在签名校验和日志序列化上），审计存储给 200G 起步。

日志容量的估算方法：单条审计记录按 2KB 算，加上调用链路的关联记录，实际膨胀系数大概是 5 倍，也就是单次调用约 10KB。4800 次/天 × 10KB ≈ 48MB/天，按 90 天留存算不到 5G。但如果你的 Agent 里有高频轮询类任务，这个数字会翻十几倍，务必按实际业务量重算。

依赖方面准备好：容器运行时、一个关系型数据库、一个对象存储（放归档日志和构建产物）、内部证书签发能力。端口规划上，控制面和管理界面走内网，工具网关单独开一个内部端口，绝对不要和管理端口复用。

# 基础目录规划示例 /opt/oce/ ├── config/ # 主配置与策略文件 ├── data/ # 注册数据、凭证缓存 ├── logs/ # 运行日志（审计日志另存） └── certs/ # 双向认证证书

3.2 最小可用配置：把关键参数一个个说明白

配置文件是落地的第一道关口，参数写错会以很奇怪的方式表现出来。下面这份是精简过的控制面配置骨架，重点看标注的几处：

# /opt/oce/config/control-plane.yaml server: listen: "0.0.0.0:8443" tls: cert_file: "/opt/oce/certs/cp.crt" key_file: "/opt/oce/certs/cp.key" client_auth: "require" # 强制双向认证，不接受匿名连接 identity: credential_ttl: "15m" # 工作凭证有效期，不超过 30m refresh_window: "5m" # 提前续期窗口，避免临界过期 clock_skew_tolerance: "60s" # 容忍节点间时钟漂移 registry: database_url: "postgres://oce:***@db.internal:5432/oce" policy_version_mode: "strict" # 策略版本严格校验，防止新旧混用 audit: sink: "http://audit-collector.internal:9200" args_mode: "hash+summary" # 绝不落原始参数 retention_days: 90 flush_interval: "2s" # 异步刷盘，平衡性能与丢失窗口 limits: global_qps: 120 per_agent_qps: 10 max_context_tokens: 32000

几个参数值得单独说。credential_ttl设 15 分钟是我反复验证过的平衡点：再短会带来频繁续期的额外请求，再长则泄漏窗口变大。clock_skew_tolerance这个参数很多人不设，结果在容器化环境里因为节点时钟不同步，出现"凭证刚签发就判定过期"的诡异现象。args_mode必须设成哈希加摘要，这一条我在后面排查部分还会提到，它是很常见的合规问题来源。

per_agent_qps这个限流值要给得保守一点。它的作用不是限制正常业务，而是防止某个 Agent 陷入循环调用时把上游打爆。我一般按业务峰值的 1.5 倍设置，宁可偶尔限流，也不要让一个失控的 Agent 拖垮整个模型接入。

3.3 Agent 清单怎么写，凭证怎么签发

Agent 清单是一份声明式文件，提交后由控制面审核并注册。清单写得好不好，直接决定了后面策略配置的复杂度：

# agent-manifest.yaml apiVersion: oce/v1 kind: Agent metadata: id: "agent-ops-alert-001" # 全局唯一，建议带业务域前缀 name: "告警分析助手" domain: "ops" owner: "运维平台组" spec: model_profile: "internal-large" # 引用模型配置档，不直接写模型名 tools: - name: "alert.query" scope: "project:alpha" # 资源级作用域，精确到项目 - name: "metric.read" scope: "project:alpha" - name: "ticket.create" scope: "queue:ops-l2" require_approval: true # 写操作强制人工确认 limits: max_turns: 8 # 单次任务最大轮次，防死循环 timeout: "180s" daily_token_budget: 800000 policy_set: "ops-baseline-v3" # 引用策略集，不内联权限

这里有两个设计取舍值得讲。第一，清单里不写模型名，只写模型档位。原因是模型会换、价格会变、版本会更迭，如果把具体模型写死在 Agent 里，将来换模型要改几十份清单。用档位抽象一层，运维侧统一调整映射关系即可。第二，写操作必须带require_approval。这条不是形式主义，它是"人在环上"的落地点。Agent 可以自主分析、自主查询，但真正产生副作用的动作，要有人点一下头。

凭证签发走命令行或者接口都行，命令行适合调试：

# 为 Agent 签发一张短期工作凭证 oce credential issue \ --agent-id agent-ops-alert-001 \ --ttl 15m \ --scope "tool:alert.query,tool:metric.read" \ --issuer control-plane \ --output /opt/oce/certs/agent-ops-alert-001.jwt # 查看某张凭证的当前状态与剩余有效期 oce credential inspect --agent-id agent-ops-alert-001 # 紧急吊销（泄漏时的第一动作） oce credential revoke --agent-id agent-ops-alert-001 --reason "suspected_leak"

吊销这一步要练熟。我建议每个团队在上线前做一次演练：假装某张凭证泄漏，看看从发现到吊销生效需要多久。如果超过五分钟，说明流程或者缓存机制有问题——凭证校验如果做了本地缓存，吊销传播就会有延迟，这时候要么缩短缓存时间，要么把吊销列表做成主动推送。

3.4 工具网关的策略配置：把权限收紧到"刚好够用"

策略是整个体系里最需要业务理解的部分。写宽松了等于没写，写严了业务跑不动。我习惯从一个"默认拒绝 + 显式放行"的基线开始：

# policy/ops-baseline-v3.yaml version: 3 default: deny rules: - id: "read-alert" allow: tool: "alert.query" actions: ["read"] resources: ["project:alpha", "project:beta"] conditions: time_window: "00:00-23:59" max_calls_per_minute: 20 - id: "create-ticket" allow: tool: "ticket.create" actions: ["write"] resources: ["queue:ops-l2"] conditions: require_human_approval: true payload_size_limit: "8KB" - id: "deny-dangerous" deny: tool: "shell.exec" actions: ["*"] reason: "生产环境禁止 Agent 直接执行脚本"

几个实操要点。默认拒绝这条一定要坚持，不然后面新增工具时会不自觉地把口子开大。资源列表要写具体标识，不要写通配符，通配符一旦写下去几乎没人会回头收紧。payload_size_limit这个条件看着不起眼，实际很有用，它能挡住 Agent 因为理解偏差把整个数据库导出结果塞进工单的情况。

策略文件我是按版本号管理的，每次变更走代码评审，变更记录和 Agent 清单的提交记录能对上。这样做的额外好处是：出问题时可以精确定位到"哪次策略变更导致了行为变化"，而不是笼统地说"最近改了配置"。

4. 让"证"真正管用的几个硬核细节

4.1 策略模型：RBAC 打底，ABAC 补位

纯 RBAC（基于角色的访问控制）在 Agent 场景里不太够用。因为 Agent 的权限不只是"能干什么"，还跟"在什么条件下干"强相关——同样的查询工具，在业务高峰期和夜间维护窗口的允许范围可能不同；同样的写操作，涉及的数据分级不同，审批要求也不同。这时候需要 ABAC（基于属性的访问控制）来补。

我的实践是两层结构：RBAC 管粗粒度，确定"这个 Agent 属于哪个角色、角色能碰哪些工具族"；ABAC 管细粒度，用属性条件做二次过滤，属性包括资源所属项目、数据分级、调用时间、调用频次、请求负载大小。两层叠加后，策略的表达能力够用，又不会复杂到没人看得懂。

这里有个坑要提醒：策略复杂度会随时间单调增长。半年后你回头看这份策略文件，大概率会发现一堆"当年为了某个临时需求加的例外"。建议每季度做一次策略清理，把过期的例外删掉，把重复的规则合并。这件事没人愿意干，但不干的话，策略会从"安全资产"退化成"没人敢动的黑箱"。

4.2 凭证生命周期：轮转、吊销、防重放

凭证不是签发完就没事了，它有一条完整的生命周期。轮转方面，工作凭证靠短期自动续期，底层用于续期的引导凭证要定期轮转，周期建议 30 到 90 天，并且轮转过程要支持新旧并存的重叠窗口，否则轮转瞬间会有一批 Agent 集体失败。吊销方面，前面提过，关键是传播速度，缓存时间要和控制面推送机制配合。

防重放是最容易被忽略的一环。凭证被截获后，攻击者未必需要重新签发，他可以直接重放之前的请求。应对办法是在请求里带上单调递增的序号或者时间戳，网关侧维护一个短期窗口内的已用序号集合，重复的直接拒绝。这个机制会增加一点内存开销，但它是短时效凭证方案的必要配套——只靠有效期不够，因为有效期内的重放完全合法。

还有一个实操细节：凭证里带的作用域要能被网关独立校验，不能只依赖 Agent 自己声明。我见过一种实现，Agent 在请求头里自己写"我要访问 A 工具"，网关就直接放行了，凭证里的作用域形同虚设。正确做法是网关从凭证签名里解出作用域，再和请求的实际目标做比对，两者不一致直接拒。

4.3 审计日志的字段设计与留存策略

审计日志的价值不在于"有"，而在于"出问题时能快速定位"。我把字段分成三类：定位类、决策类、成本类。

留存策略上，我建议分两级：热数据保留 30 到 90 天，支持即时查询；冷数据归档到对象存储，保留一年以上，用于合规审查和长期趋势分析。归档时记得做压缩和索引重建，不然一年后想查的时候会发现根本检不出来。

注意：审计日志本身也是敏感数据集合。它记录了 Agent 访问了哪些资源、在什么时间访问，这些信息聚合起来能推断出业务节奏和系统结构。日志库的访问权限要单独控制，不要和普通运维权限混在一起。

4.4 沙箱与出口管控：把"唯一出口"落到实处

沙箱配置的核心目标是让 Agent 即使被诱导、被注入，也做不到越界操作。具体措施包括：根文件系统只读，临时目录单独挂载并限制容量，禁用特权模式，系统调用白名单收窄到实际需要的那几个，网络出口只允许到工具网关。

这里我想强调一个常被低估的点：临时目录的容量限制。Agent 处理数据时很可能把中间结果写到磁盘，如果不限制，一个处理大文件的 Agent 能把节点磁盘写满，进而影响同节点上的其他服务。给个 2G 上限，超了让它失败，比拖垮整台机器好。

出口管控要靠基础设施层的网络策略做，不要指望应用层配置。应用层配置的好处是灵活，坏处是可能被绕过；网络策略是硬的，配错了会直接不通，反而容易发现。两者结合最稳：网络层只放通到网关，应用层再做工具级的细粒度控制。

5. 常见问题与排查实录

5.1 部署与连通性问题的速查表

自托管方案的问题分布很集中，八成出在证书、网络和时钟上。整理成表方便对照：

时钟问题我要多说一句。容器化环境里，节点时间不同步是常态，尤其是有节点重启之后。表现出来就是"凭证校验随机失败"，而且换个节点又好了，特别迷惑人。解决办法是在配置里留出容忍窗口，同时在监控里加一条"节点时间偏差"的告警，超过 30 秒就报出来。

5.2 权限类问题：401、403、作用域不足怎么区分

这三类错误长得像，处理思路完全不同，一定要分清。

401 未认证，通常是凭证本身的问题：过期、签名不对、签发者不匹配。排查顺序是先看凭证有效期，再看签发者是否在信任列表里，最后看签名算法是否一致。403 已认证但被拒，是策略问题：要么作用域不覆盖目标资源，要么条件不满足（比如时间窗、频次超限、需要审批但没走审批）。这时候要去查审计日志里记录的策略命中规则，日志会直接告诉你命中了哪条 deny。作用域不足最隐蔽，凭证有效、策略也放行了，但凭证里带的作用域比策略要求的窄，网关在二次校验时拒掉。

我的经验是，把这三类错误在网关侧映射成不同的错误码并且带明确提示，能省掉大量沟通成本。最糟糕的实现是统一返回"权限错误"，然后大家一起去翻日志。

5.3 模型与工具调用类问题：超时、上下文、工具幻觉

这类问题跟治理无关，但实际运维中占比很高。超时最常见的原因是工具本身慢，而不是模型慢。排查方法是看调用链路里各段的耗时分布，如果工具调用占了 80%，那优化方向是给工具加超时和降级，而不是换模型。上下文超限发生在 Agent 轮次多、每轮都往上下文里塞工具返回结果的时候，解决办法是给工具返回做截断和摘要，只保留关键字段，别把原始 JSON 整个塞进去。

工具幻觉是 Agent 领域特有的问题：模型调用了清单里根本不存在的工具，或者参数结构对不上。前者的处理很简单，网关直接拒绝并返回可用工具列表，让模型自我修正；后者需要在工具描述里把参数约束写清楚，尤其是必填项和枚举值。我踩过一个坑，某个工具的可选参数写得太含糊，模型每次都自己编一个值传进去，导致下游频繁报参数错误，后来把参数描述改成"必须是 A、B、C 之一，不传则默认 A"，问题立刻消失。

5.4 成本与性能：限流、缓存、预算控制

成本问题的根源往往是"没人在看"。三件事做到位基本能控住：按 Agent 设日预算，超了就降级或者停用，别让它无限跑；做结果缓存，同样的查询在短时间内重复请求很常见，缓存命中率通常能到两三成；限制单次任务的轮次和 token，这一条最有效，因为绝大多数成本爆炸都来自 Agent 陷入循环，一轮轮地试错。

性能上，网关是同步阻塞的，并发上来后容易出现排队。我的做法是把日志写入和审计上报做成异步，主链路上只做校验和转发，这样单机能扛的并发能提升不少。当然异步带来的是丢失窗口，所以刷盘间隔要短，丢一点日志可以接受，丢大量日志就不行了。

6. 落地节奏和我踩过的坑

6.1 三步走：影子模式、灰度、全量

一次性全量上线 Agent 是很危险的做法。我推荐三步走。第一步影子模式，Agent 正常接收任务、正常调用工具做查询，但所有写操作只记录不执行，日志里标记为"模拟"。这个阶段跑一到两周，主要看两件事：Agent 的调用路径是否符合预期，有没有出现清单外的工具调用请求。第二步灰度，选一到两个低风险业务放真实执行，写操作强制人工确认，观察人工确认的通过率和驳回原因，驳回原因是最有价值的反馈，它能直接告诉你策略哪里写宽了或者提示词哪里没写清楚。第三步全量，逐步放开写操作，同时把人工确认收敛到真正高危的动作上。

这个节奏看着慢，实际上比"先上线再修"快。因为影子阶段能把绝大部分低级错误挡在前面，省掉的是后面手忙脚乱救火的时间。

6.2 几个印象深刻的坑，都是真金白银换的

第一个坑：共享万能凭证。早期图省事，几个内部 Agent 共用一张凭证，理由是"反正都是自己人"。结果某天一个 Agent 出现异常高频调用，限流按凭证维度生效，把另外几个正常 Agent 一起限死了。更麻烦的是审计日志里所有调用都记在同一个主体上，根本分不清是谁干的。后来改成每个 Agent 独立凭证，问题迎刃而解。这件事让我彻底明白，凭证的粒度就是治理的粒度。

第二个坑：日志里的敏感信息。有次排查问题需要看工具入参，发现日志里完整记录了某次查询的身份证号。虽然日志库在内网，但这个记录本身就是隐患。改成哈希加摘要之后，虽然排查时要多一步反查，但合规风险没了。这个改动当时被业务方抱怨过，后来安全评审的时候，这条是加分项。

第三个坑：提示词里的工具描述太长。为了让模型准确调用工具，把每个工具的描述写得跟文档一样详细，结果上下文里一半 token 花在工具描述上，成本翻倍还挤占了推理空间。后来把描述精简到"做什么、什么时候用、参数约束"三句话，准确率没降，成本降了三成多。这件事的教训是：给模型的说明要像给新同事的口头交代，不是写给文档评审看的。

第四个坑：版本升级没做兼容测试。有一次升级控制面，凭证格式微调了字段名，结果执行面还是老版本，新旧对不上，整个链路中断了二十分钟。后来定了规矩：控制面和执行面必须支持至少一个版本的向下兼容，升级顺序固定为先执行面后控制面。这个规则写进了变更流程，比任何口头提醒都管用。

6.3 上手前值得先想清楚的三件事

第一，你真正要治理的是什么。如果只是内部几个查询类 Agent，那重点在审计和限流，凭证体系可以简化；如果涉及写操作和跨系统调用，那凭证和策略就是刚需，不能省。第二，谁来负责日常运维。自托管方案的运行责任是明确的，得有人管升级、管证书、管容量。这个人不一定全职，但必须指定。第三，人工确认的边界划在哪里。全都要确认，Agent 就没价值了；全都不确认，风险兜不住。我的经验是把"不可逆操作"和"影响外部用户的操作"划进确认范围，其余放开。

最后分享一个小技巧：给每个 Agent 建一个"行为基线"。上线第一周记录它的正常调用模式——平均轮次、常用工具、典型耗时。之后每周和基线比一次，偏差超过阈值就人工看一眼。这个机制成本极低，但能提前发现很多问题，比如提示词被改动导致的路径漂移、上游工具变更导致的重试暴增。比起事后从几千条日志里捞异常，这种横向对比的效率高得多。