--- kind: ideas granularity: day period_start: '2026-06-28T00:00:00' period_end: '2026-06-29T00:00:00' run_id: materialize-outputs status: succeeded topics: - AI agents - credential security - coding agents - agent workspaces - model routing - software economics tags: - recoleta/ideas - topic/ai-agents - topic/credential-security - topic/coding-agents - topic/agent-workspaces - topic/model-routing - topic/software-economics language_code: zh-CN --- # 受控的工程智能体工作流 ## 摘要 智能体采用在权限、任务范围和评审成为工作流一部分的地方最实用。近期最清楚的变化是用于智能体执行的凭据别名、通过团队工具分配小型工程任务，以及面向同时运行多个 coding-agent 会话开发者的操作队列。 ## 用于智能体和 MCP 工具执行的凭据别名 安全团队在给智能体开放内部工具的广泛访问权限之前，应该先测试一层智能体凭据层。具体改动是：不要再把可复用的 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 秒删除了生产数据库。 ### 资料来源 - [AI Agent Credential Crisis: Six Months of Incidents](../Inbox/2026-06-28--ai-agent-credential-crisis-six-months-of-incidents.md): 概述了凭据别名方法、有范围限制的凭据、会话监控、撤销声明和事故指标。 - [AI Agent Credential Crisis: Six Months of Incidents](../Inbox/2026-06-28--ai-agent-credential-crisis-six-months-of-incidents.md): 给出了文中引用的 secret 暴露规模和具体智能体相关事故数字。 - [AI Agent Credential Crisis: Six Months of Incidents](../Inbox/2026-06-28--ai-agent-credential-crisis-six-months-of-incidents.md): 说明了用于限定智能体任务以及身份/权限风险的最小代理原则。 ## 通过 Slack 和工作区分配小型代码修复，并保留 PR 评审 工程团队可以把低风险修复交给请求已经出现的地方处理，同时让代码合并继续走常规评审。这个工作流应保持狭窄：队友在 Slack、Notion 页面、任务或评论中标记一个智能体；智能体找到相关 handler，做一个小补丁，新增或更新测试，打开 GitHub PR，并把链接发回原线程。 CrewAI 的 Iris 示例说明了为什么小任务值得这样试。一个设置页 bug 会导致带尾随换行符的复制 API key 无法通过校验。修复只需要两行代码，但人工流程需要离开 Slack、暂存当前工作、创建分支、打开编辑器、运行 Claude Code、检查 diff、合并、部署，再回到 Slack。Iris 在大约三分钟内打开了一个 PR，并添加了换行符测试。Notion 的 /Dev 产品也指向同一种工作区智能体运行模式：@mention、共享权限、可见的工具调用，以及团队工作区内的评审或审批点。 试点应只允许小型、可回滚的变更进入，并要求指定评审人和必需测试。在团队测量合并率、评审时间、回滚率，以及智能体造成额外评审负担的频率之前，复杂工程工作应留在队列之外。 ### 资料来源 - [My coworker Iris isn't a person](../Inbox/2026-06-28--my-coworker-iris-isn-t-a-person.md): 概述了 Iris 作为 Slack 智能体处理小型工程任务的方式，并给出了三分钟 PR 示例。 - [My coworker Iris isn't a person](../Inbox/2026-06-28--my-coworker-iris-isn-t-a-person.md): 描述了九步人工流程、空白字符修剪 bug、PR 和新增的换行符测试。 - [/Dev/Notion](../Inbox/2026-06-28--dev-notion.md): 描述了 @mention 智能体、Notion Workers、共享界面、权限，以及评审或审批点。 ## 面向同时运行多个 coding-agent 会话开发者的等待状态队列 同时运行多个 Claude Code 会话的开发者需要一个队列，显示哪个智能体被阻塞，并让他们快速跳转过去。Mux 在 tmux 中给出了一个具体版本：它读取 Claude Code 状态文件，把它们匹配到实时 pane，打开一个 fzf overlay，把等待中的会话排在工作中和空闲会话前面，显示状态持续时间和实时预览，并用 Enter 切换到选中的 pane。 这是一个可用于终端、IDE 和内部开发者工具的模式。队列应显示状态、仓库或工作目录、距上次状态变化的时间、当前请求，以及下一步需要人工执行的动作。它还应带上日常 coding-agent 使用中的简单护栏：要求智能体在编辑前说明计划，尽可能把改动限制在一两个文件内，并在改动超过 100 行或跨多个文件时要求批准。 低成本验证方法是比较一周内有队列和无队列的并行智能体工作。可用指标包括处于等待状态的时间、错过的提示数量、评审返工，以及开发者终止或重启会话的频率。 ### 资料来源 - [Mux – A tmux overlay for managing Claude Code sessions](../Inbox/2026-06-28--mux-a-tmux-overlay-for-managing-claude-code-sessions.md): 概述了 Mux 面向 Claude Code 会话的队列、状态排序、实时 pane 匹配和跳转行为。 - [Mux – A tmux overlay for managing Claude Code sessions](../Inbox/2026-06-28--mux-a-tmux-overlay-for-managing-claude-code-sessions.md): 展示了 overlay 字段、等待优先排序、实时预览和一键 pane 跳转。 - [The Usefulness of AI Agents](../Inbox/2026-06-28--the-usefulness-of-ai-agents.md): 列出了实用的 coding-agent 护栏：编码前制定计划、聚焦改动，以及较大变更需要批准。