最近 Grok Bot 引发关注，不只是因为“AI 能替人操作电脑”。xAI 在 9 月 3 日发布的设计文章里，给出了一个更值得企业产品经理和技术负责人注意的变化：产品的主要对象不再是聊天记录，而是持久、具名的 Bot 名册。
这看似只是侧边栏改版，实质上改变了系统要管理的对象。
聊天会话回答的是：这次聊了什么？
AI 员工还必须回答：谁长期负责这项工作？它应该记住什么？允许使用哪些工具？什么事件会让它开工？交付到什么状态？什么时候必须找人确认？
从 Session 到 Role，差的不是一段 memory
给每个 Agent 保存历史消息，只能得到“更长的会话”。岗位是一组稳定约束，至少包含六个部分：
| 身份与职责 | 谁负责，负责到哪里 | 多个 Agent 都以为别人会收尾 |
| 岗位上下文 | 哪些资料需要长期保留 | 所有资料混成一个超长上下文 |
| 工具与账号 | 能读、能写、能提交什么 | 有工具就默认拥有全部权限 |
| 触发方式 | 人、日程、事件还是其他员工启动 | 没人发消息就永远停着 |
| 交付物 | 最终落到文档、表格还是平台草稿 | 只在聊天框里说“已完成” |
| 人工确认 | 哪些外部影响必须暂停 | 把草稿完成误当成可以直接发布 |
xAI 的最新说明把这一点说得很具体：Bot 有自己的身份、记忆、运行环境和工具；工具与 Skills 可以在账户层共享，但记忆与 Routines 属于具体 Bot。也就是说，能力可以复用，上下文仍要跟着岗位走。
这比“所有 Agent 共用一个知识库”更接近企业现实。内容编辑需要品牌资料，财务岗位需要账务记录，销售岗位需要客户跟进历史。它们可能共同使用浏览器和文档工具，却不应该默认读取彼此的全部资料。
一个可落地的岗位配置模型
可以先用一张岗位卡把对象固定下来：
role:
name: 公众号编辑
responsibility: 从选题到发布前草稿
context:
– 品牌口径
– 历史选题
– 本周活动资料
tools:
read: [资料库, 官方来源]
write: [文章草稿, 配图]
confirm: [平台提交]
triggers:
– 周一选题会
– 新活动资料到达
deliverables:
– 母题大纲
– 正文与配图
– 平台字段预填
stop_when:
– 账号不确定
– 来源无法核验
– 分类或提交状态不明
这张卡不是另一种 Prompt 模板。Prompt 描述一次请求，岗位卡定义长期责任。一次任务失败后，系统也能明确记录失败发生在哪个对象：资料缺失、工具不可用、账号不符，还是需要人工审批。
为什么国内企业不该从空白智能体开始
Grok Bot 的官方资料强调，用户可以创建具名 Bot，给它任务、上下文和工具，并通过实际示范把流程保存为 Routine。这条路径让“AI 是可以分配工作的队友”变得非常直观。
但对多数国内经营者和小团队，真正的门槛常常不是会不会输入指令，而是能否把一个岗位定义完整。若从空白 Agent 起步，企业仍需自行决定职责、资料边界、工具组合、工作方法、交付格式和审批位置。
Tipkay 可以理解为更适合国内企业的落地版本：理念一致，但在预设岗位和国内企业场景上走得更进一步。小红书运营、抖音运营、公众号编辑、视频制作、PPT 制作等岗位所需的经验、流程、模型和工具已按岗位组合；企业提供业务资料和目标后，可以从调研、规划和内容创作继续推进到视觉制作、平台适配与发布准备，同时也能继续创建和配置专属员工。
这里的重点不是“预设就永远不改”，而是把起点从空白智能体改成一份可审阅的岗位定义。企业先获得能工作的岗位，再按自己的品牌、流程和权限做增量配置。
上线前，检查这六个问题
Grok Bot 让“AI 从聊天工具变成可分配工作的员工”获得了更清晰的产品形态。企业真正需要补上的下一步，是把一排会聊天的头像，变成一份职责清楚、边界可控、交付可验收的岗位名册。
参考：
- https://x.ai/news/designing-grok-bot
- https://docs.x.ai/grok-bot/overview
