从工程团队起步，分批推广企业 Agent

Block 约用八周，将 Goose 推广至 1.2 万名员工。这个起于开发任务自动化的工具，后来被重建为 MCP 客户端并开源。现有节选讨论的重点，是如何从工程团队逐步扩展到其他岗位，以及接入更多企业系统后，怎样控制敏感信息泄露风险。

目前能确认什么

Goose 最早服务开发者，早期接入的 MCP server 包括 GitHub。随后，财务、营销、销售、设计等岗位提出需求，Block 为员工补建了更多 MCP server。

MCP（Model Context Protocol）是连接 AI 应用与工具、数据源的协议。接通系统只是第一步，Agent 能读取什么、执行什么，仍需要权限控制。

据 Block 的 Angie Jones 介绍，新增 MCP server 都要经过安全审查，内部自建的也不例外；不在允许列表中的连接器无法运行。被标记为可修改、编辑或删除的操作，需要用户查看意图并确认。自有 MCP 服务则接入企业身份提供商，减少员工手动配置凭据的负担。

节选也提到，红队曾在共享工作流 recipes 中发现不可见字符。这类内容可能诱导 Agent 执行有害操作，属于提示注入风险。

按岗位分批放行、用任务耗时决定是否扩围，是文章作者的建议，不能直接当作 Block 的完整实施流程。

我的判断

对准备做内部 Agent 的程序员，这个案例最有用的是扩围条件：新岗位需要的连接器是否齐备、是否审查过、写操作能否由人确认。其他部门提出需求，可以启动试点，但不足以证明已经具备全员开放的条件。

推广人数不能直接当作活跃使用人数，更不能当作收益证明。

节选中的五分钟提交 PR、冲刺提前完成，都是受访者描述的案例，缺少任务难度、人工复核和质量数据。现有材料也未交代敏感数据如何限制外发、操作如何审计，以及出现泄露后怎样处置。这些细节仍需完整原文或官方文档确认，不能仅凭连接器白名单就判断安全闭环已经成立。