内部智能体的运行控制

在同一个代码库中运行多个编码智能体的团队，可以为每个任务加一层小型控制：一个 Git worktree、一个租约文件、一个门禁结果，以及一个状态包，列出任务拥有的文件、已改动文件、命令、测试和证据。GlueRun-go 展示了这种模式的具体实现。它的 worker 会写入一个有 schema 支持的数据包，auditor 检查数据包和门禁结果，确定性 decider 在使用模型兜底前选择重试、改变范围、升级或搁置。

有用的测试是运行层面的。在一个带有真实测试命令的代码库中，让两三个智能体处理彼此独立的任务，然后检查评审者能否在先不阅读每个 diff 的情况下回答三个问题：这个任务拥有哪些文件，产出了什么证明，门禁失败后应该怎么处理。GlueRun-go 报告称，分离式调度让 gluerun reconcile --actuate 在数秒内返回，同时 worker 继续在后台运行；崩溃检测也从 60 分钟的过期租约窗口降到约一个 reconcile 周期。对于当前智能体运行会留下过期分支、所有权不清或难以评审变更的团队，这足以支持一次试用。

内部智能体需要一个记忆层，在智能体行动前说明哪些声明有支持、已过期、相互矛盾或缺失。Vitrus 给出了可构建的形式：把 Markdown 和带类型的边 sidecar 作为事实来源，把索引作为可丢弃基础设施重建，并返回带来源、置信度、新鲜度和确定性缺口列表的答案。它的 API 路径还增加了一项有用控制：导入 OpenAPI 规范，搜索正确端点，验证端点名称和参数，然后只在调用通过检查后执行。

这适合内部支持智能体、入职引导智能体，以及已经会查阅 runbook、决策记录、工单和 API 文档的工程助手。首次部署可以限定在一个服务领域，并用简单失败案例来评估：无支持的答案、过期决策、缺失的引用文档、已废弃端点、错误参数类型和未授权结果。Vitrus 报告称其 eval gate 上的 source-hit ≥90%，在受控合成语料上的缺口召回率和精确率均为 100%，ACL 泄漏测试中未授权结果为 0，并有超过 200 项测试。缺口结果来自合成语料，因此上线范围应保持较窄，但其机制已经足够具体，可以用于服务团队试点。

让智能体访问 IT 系统的公司，应在日志中区分智能体身份和人类身份，同时保留人类负责人。Amazon 描述的模式很具体：日志显示某个具名智能体代表某个具名人类执行了操作，权限按任务限定，破坏性操作有静态防护栏，被阻止的操作会返回生产影响等原因。这个原因很重要，因为只看到通用权限失败的智能体，可能会尝试另一条路径来完成同一个有害任务。

一个实际采用检查是，为一个内部智能体配置独立账号、任务专用策略，以及针对影响生产操作的拒绝消息。审计日志应能回答谁拥有该请求、哪个智能体执行了操作、它触达了什么资源，以及任何被阻止的操作为何被阻止。Amazon 没有提供基准或量化安全结果，因此这应被视为一种治理设计，并在有边界的工作流中测试，例如数据库维护请求或由工单驱动的基础设施变更。