智能体开始“自己开工”后，企业该补一张运行时执行卡

过去，企业给智能体的典型指令是“帮我查一下”“帮我写一版”。现在，边界正在变：它会记住团队已做的决策，穿过多个系统取回上下文，在固定时间执行任务，也能在一条消息或一个表情出现时自动启动。问题随之不再只是“它答得对不对”，而是：它为什么在这一刻启动、用了哪些当时有效的信息、完成了什么动作，以及谁能及时叫停。

Slack 在6月披露，Slackbot 已能在日程触发、频道消息到达或用户添加表情时启动任务；它还通过 MCP 连接 Google、Atlassian、Box、Notion、DocuSign 等系统。其官方案例中，一位销售工程师把通话后的活动记录做成可共享技能，三周内有466名同事使用；Slack 披露的人均节省时间为每周43分钟。这个数字是单一案例，不能外推为普遍收益，但它清楚地说明了一个变化：个人提示词正在变成可传播、可触发、可执行的团队能力。

从“助手响应”到“事件驱动”，风险的单位变了

被动式助手的风险相对直观：员工提问，系统给出回答或草稿，错误通常停留在一个会话里。事件驱动的智能体不同。一次频道触发，可能读取项目上下文、检索外部资料、更新CRM记录、创建共享文档，再把结果发回团队。每一步单独看都合理，连起来却可能在不合适的时点扩大影响。

因此，权限清单仍然重要，但只回答“能不能做”。企业还需要回答“什么时候能做、什么事件让它开始、用的是哪个时点的证据、这一次是否该继续做”。当自动化从手动点一下变为日程、消息、反应等触发器时，治理对象应从静态角色权限扩展到运行时行为。

给每类自动任务一张“运行时执行卡”

我建议企业不要先按产品品牌整理智能体，而是给每一类自动任务建立一张可审阅的运行时执行卡。它不是一份冗长审批表，而是让业务、IT和风险负责人对同一份运行规则达成共识。

“会记忆”不等于“可放心执行”

长期上下文能减少重复交代，也让智能体看起来更懂团队。但企业应把“记忆”拆成三个问题：这份信息是否仍有效？当前任务是否真的需要它？这次调用是否该留下可复核的证据？Slack 的帮助文档说明，Slackbot 的回答基于用户原本有权访问的信息，编辑共享 Canvas 时还要求用户确认才会写入。这类设计提供了有价值的基线，但落到企业内部，仍要把读取范围、写入动作和确认点按任务颗粒度写清楚。

尤其是团队把经验做成技能并复用时，最容易被复制的不只是效率，也可能是过期口径、隐含假设和不合适的动作权限。好的能力资产不是“一个能跑的提示词”，而是带着适用条件、证据范围、验收标准与退役日期的可运营单元。

STARBOX视角：把自动化的每次启动，变成组织可学习的样本

在STARBOX看来，企业不该只把智能体当作更快的交互界面。组织层要定义哪些事件值得自动化、哪些动作必须升级；BOX层要沉淀任务卡、知识口径、触发条件、成功样例与失败样本；智能体层才在这些边界内检索、生成和执行。通过DDABC闭环，误触发、人工叫停、被退回的结果不应只是一条日志，而要被归因到触发规则、知识、权限、任务设计或验收标准，并回写下一次运行。

我的判断是：智能体规模化的下一个瓶颈，不是再接入多少应用，而是企业能否把“自动开始工作”这件事本身治理好。能被可靠复用的，不是某个聪明回答，而是一张能说明何时启动、依据什么、允许做到哪里、出错后如何收回的运行时执行卡。

当你的智能体下一次因为一条消息、一个日程或一个表情自动启动时，不妨先问一句：如果三个月后要复盘这次行动，团队能不能完整说清它为什么开始、看到了什么、做了什么、又是谁为结果签字？这张卡，可能比多接一个工具更值得先做。