External Agent Trust Boundary：让 Codex 这类外部 Agent 进工作流前先过信任边界

External Agent Trust Boundary 是外部 Agent 进入业务工作流前必须经过的信任边界：它规定谁授权、能访问哪个 workspace、能调用哪些工具、产物如何审核、哪些动作必须人工确认，以及失败后如何停止或回退。团队每天把文件、脚本、API 和发布后台交给 Agent 时，真正的痛点不是能力不够，而是人工追责困难、重复检查低效、误发误删风险高。Codex、Claude、Manus 或其他外部 Agent 越强，这个边界越重要。没有边界的外部 Agent 不是数字员工，而是一个权限过宽的黑盒。

OpenAI Developers 的 Codex use cases 覆盖 workflow、automation、engineering 和 knowledge work；OpenAI code generation guide 涉及 CI/CD pipelines with SDK 和不同使用入口；NIST 的 AI Risk Management Framework 则把治理、映射、测量和管理作为 AI 风险管理的重要结构。Axon 的 External Agent Trust Boundary 就是把这些风险语言翻译成白领能执行的 workflow 控制。

外部 Agent 的能力越像员工，它越需要入职规则、权限范围、工作记录和交付验收，而不是更长的 prompt。

信任边界先于自动化

很多团队在接入外部 Agent 时先问“它能做什么”。更好的问题是“它不应该做什么”。这听起来像限制能力，实际上是在保护可持续自动化。一个 Agent 如果能读所有文件、改所有脚本、访问所有工具、自动发布结果，那么它的每次成功都带着隐藏风险。

边界	应该提前定义什么	不能靠什么临时补救
身份	谁授权外部 Agent、授权多久	运行后再追问是谁批准
workspace	能读写哪些目录和文件类型	让 Agent 自己判断敏感文件
工具	shell、network、browser、API 的权限	出错后再删日志
产物	输出路径、格式、验收人	只看最终自然语言总结
不可逆动作	发布、删除、覆盖、发信、更新记录	默认自动执行

Axon 的 Trust Mode 应该把这些问题前置。外部 Agent 不是不能用，而是必须先进入可解释、可撤销、可确认的运行轨道。

权限梯子

externalAgentTrustBoundary:
  identity:
    actor: "authorized Codex external agent"
    owner: "workflow owner"
  workspace:
    read:
      - "./approved-source"
    write:
      - "./draft-artifacts"
  tools:
    shell: "confirm"
    network: "confirm"
    backendSubmit: "auth"
  artifacts:
    reviewRequired:
      - "article markdown"
      - "cover webp"
      - "dry-run output"
  stopRules:
    - "missing product evidence"
    - "attempt to publish before approval"
    - "workspace path outside allowed scope"

这不是技术团队自嗨的配置文件，而是业务 owner 能读懂的权限梯子：自动做什么、确认做什么、授权做什么、触发什么就停。

四个最容易被忽略的风险

第一，外部 Agent 看到太多。
为了“帮得上忙”，团队常把更多文件塞给 Agent。结果是上下文变厚，权限变宽，隐私和误引用风险上升。Axon 应该用 workspace-scoped workflows 把输入范围写清楚。

第二，外部 Agent 改得太快。
Codex 擅长批量修改文件，但业务文件、发布脚本和配置文件不应该同一权限处理。能改草稿，不等于能改线上配置。

第三，外部 Agent 解释得太顺。
自然语言总结可能很流畅，但缺少证据。信任边界要求每个关键动作都有产物路径、日志或 span，而不是“我检查过了”。

第四，外部 Agent 发布得太早。
最危险的不是生成错误草稿，而是把错误草稿直接推到用户面前。发布、发送、删除、覆盖、调用运营后台都应该进入 auth 或 confirm。

用状态机管理外部 Agent

External Agent Trust Boundary 最好不要只写在政策文档里。它应该进入 Workflow State Machine：draft、dry-run、waiting-confirmation、running、exception、accepted、archived。外部 Agent 的每个动作都应该让状态前进或停下。

步骤 1：进入 running 前，验证授权、workspace 和 Source Data。步骤 2：进入 waiting-confirmation 前，展示产物和 dry-run 结果。步骤 3：进入 accepted 前，确认 owner 明确批准。这个三段式比“Agent 运行完成”更适合企业流程。

事件样例

{
  "event": "external_agent_publish_blocked",
  "agent": "Codex",
  "reason": "human approval missing",
  "currentState": "waiting-confirmation",
  "artifact": "dry-run-report.txt",
  "nextAllowedAction": "request_owner_review"
}

这样的事件能被 Workflow Telemetry Spans 使用，也能帮助团队复盘：不是 Agent 没完成，而是它正确地停在了信任边界。

常见问题

Q1：信任边界会不会拖慢外部 Agent？
会增加少量前置配置，但会减少误改、误发和无法解释的返工。对企业流程来说，速度必须服从可控性。

Q2：哪些动作一定要人工确认？
发布、删除、覆盖、发信、调用生产 API、更新客户或财务记录、改变权限配置，都应该进入 confirm 或 auth。

Q3：外部 Agent 失败时应该自动重试吗？
只有低风险、幂等、范围清楚的步骤可以自动重试。涉及权限、事实不确定或产物质量不足时，应进入 fallback 或人工 review。

先画边界，再谈自动化

如果你准备把 Codex 或其他外部 Agent 接入 Axon，不要先写最长的 prompt。先写 External Agent Trust Boundary：身份、workspace、工具、产物、stop rules 和审批动作。再结合 Trust Mode、workspace boundary、state machine 和 source lineage，了解更多外部 Agent 治理方式，并开始使用 Axon 把外部 Agent 放进一条可控 workflow。这样做不会削弱 Agent，反而会让它更像一个可以被团队长期使用的 AI 数字员工。