受控的工程智能体工作流

安全团队在给智能体开放内部工具的广泛访问权限之前，应该先测试一层智能体凭据层。具体改动是：不要再把可复用的 API key、OAuth token、session token 和构建凭据放在 MCP 配置、IDE 插件、CI 任务、本地文件或智能体运行时上下文中。智能体拿到的是有范围限制的别名或隔离标识符；真实凭据留在受控基础设施中，由它签名 payload、执行范围限制、校验时间戳、阻止重放、轮换密钥并撤销会话。

第一个有用的检查可以很小：盘点一个已启用智能体的工作流，把其中的直接 secret 换成别名，然后做一次撤销演练。演练应记录被阻止的智能体是否在承诺时间窗口内失去访问权限，合法运行是否继续，以及审计轨迹是否足够清楚，可用于事件响应。这个问题已经有实际事故支撑：DevFortress 文章引用的数据称，2025 年 public GitHub 上暴露了 28,649,024 个新 secret，2022 年泄露的凭据中有 64% 到 2026 年 1 月仍然有效且可被利用，MCP 配置文件中发现了 24,008 个唯一 secret。文章还引用了一起事故：一个 Cursor 智能体在发现一个未限定范围的 Railway CLI token 后，用 9 秒删除了生产数据库。

工程团队可以把低风险修复交给请求已经出现的地方处理，同时让代码合并继续走常规评审。这个工作流应保持狭窄：队友在 Slack、Notion 页面、任务或评论中标记一个智能体；智能体找到相关 handler，做一个小补丁，新增或更新测试，打开 GitHub PR，并把链接发回原线程。

CrewAI 的 Iris 示例说明了为什么小任务值得这样试。一个设置页 bug 会导致带尾随换行符的复制 API key 无法通过校验。修复只需要两行代码，但人工流程需要离开 Slack、暂存当前工作、创建分支、打开编辑器、运行 Claude Code、检查 diff、合并、部署，再回到 Slack。Iris 在大约三分钟内打开了一个 PR，并添加了换行符测试。Notion 的 /Dev 产品也指向同一种工作区智能体运行模式：@mention、共享权限、可见的工具调用，以及团队工作区内的评审或审批点。

试点应只允许小型、可回滚的变更进入，并要求指定评审人和必需测试。在团队测量合并率、评审时间、回滚率，以及智能体造成额外评审负担的频率之前，复杂工程工作应留在队列之外。

同时运行多个 Claude Code 会话的开发者需要一个队列，显示哪个智能体被阻塞，并让他们快速跳转过去。Mux 在 tmux 中给出了一个具体版本：它读取 Claude Code 状态文件，把它们匹配到实时 pane，打开一个 fzf overlay，把等待中的会话排在工作中和空闲会话前面，显示状态持续时间和实时预览，并用 Enter 切换到选中的 pane。

这是一个可用于终端、IDE 和内部开发者工具的模式。队列应显示状态、仓库或工作目录、距上次状态变化的时间、当前请求，以及下一步需要人工执行的动作。它还应带上日常 coding-agent 使用中的简单护栏：要求智能体在编辑前说明计划，尽可能把改动限制在一两个文件内，并在改动超过 100 行或跨多个文件时要求批准。

低成本验证方法是比较一周内有队列和无队列的并行智能体工作。可用指标包括处于等待状态的时间、错过的提示数量、评审返工，以及开发者终止或重启会话的频率。