Grok Bot 团队：先让智能体能自查，再扩大自主权

Lauren Tan 和 Roman Ugarte 说，他们的团队用了七周，将 Grok Bot 从内部原型推向发布。产品围绕拥有身份、工具和职责的持续运行的机器人组织，而不只是围绕聊天或文件。

Ugarte 说，团队希望非工程师也能受益于长时间运行的编程智能体给工程工作带来的变化。机器人应能使用人们熟悉的工具，主动带回工作成果或信息。

最初的内部用户既有 AI 爱好者，也有此前很少使用 AI 的同事。Ugarte 说，人们可以从简单任务开始，随后配置机器人，并在建立信任的过程中逐渐赋予它更广泛的职责。

他举例说，一个营销机器人拥有广告账号的访问权限和预算，与设计机器人合作测试广告素材。支持机器人则可以复现问题并协助处理不断涌入的工单。

Tan 用机器人构建工程工作的外层循环。她不必再从 Slack 收集上下文并复制到编程工具，而是可以把智能体带进错误报告或功能需求所在的对话。

用户可以按职能、客户或二者的组合来组织机器人。Tan 偏好数量较少、其中包含一些专家的团队；Ugarte 则喜欢让每个机器人关注一个明确问题并主动报告发现。

Ugarte 将机器人负责人的角色比作指导学徒的领域专家。他认为，这可以让企业更容易把智能体用于特定结果，而不是依赖单一通用助手。

团队机器人可以在公司内部共享。喜欢构建自动化的同事可以花几小时搭建工作流，随后让其他人共同使用和改进，而不是各自维护副本。

Tan 展示了销售方面的例子：共享专家机器人研究潜在客户并处理运营步骤。工程机器人同样整合了全团队都能使用的技能和实践。

共享工作也带来模糊地带。Ugarte 说，群聊中的机器人可能不知道谁具有相关专业知识或决策权；产品需要更好地表达这些关系。

几人讨论是否可以利用机器人所有者、管理者和协作者的信息判断权限。更广泛的问题是，多个人或机器人参与同一工作流时，智能体应如何理解指令。

Tan 介绍如何在 Slack 中让机器人之间的协作可见。她的工程机器人可以向数据机器人询问某个用户问题是否普遍，而她可以直接看到对话，无须事后重建过程。

Ugarte 建议分阶段建立信任。数据机器人可以先拥有数据库只读权限并回答问题；人们观察它可靠完成工作后，再考虑允许它执行操作或承担更广泛的目标。

谈及开发循环，Tan 描述了自己、同事和机器人在 Slack 线程中协作的过程。她分享一段视频，询问要构建类似功能需要做什么。

机器人启动了一个带虚拟机的 Cursor 云端智能体，后者运行应用、制作原型并返回截图和视频。其他同事可以加入线程，在工作进行时提供反馈。

Tan 说，一个功能通过共享线程中约 200 条消息完成开发，她本人没有为这个项目打开 Cursor。团队查看产出并共同迭代，然后发布。

建立这种自主程度花了时间。Tan 说，团队投入了技能、代码库约束、静态分析和工具，把反复出现的审查要求写进系统，而不是每次都由人处理。

在这套设置中，她的智能体可以合并自己的拉取请求。她说，展示的例子中，她查看了产出物，而没有逐行阅读拉取请求。

Tan 解释了 pstack，即 potato stack：一组受到 GStack 启发、通过 Cursor 插件仓库公开的个人工程技能。她把这类工具比作厨师去新厨房工作时带上自己熟悉的刀具。

一位主持人描述了自己的软件工厂：多个线程同时工作，由协调者从过往交互中了解他的偏好。他用它寻找其他工具集中的有用方法，并调整到自己的工作流中。

Ugarte 说，在公开 Slack 线程里工作有助于传播知识。同事可以看到熟练用户如何调用智能体，之后自己也采用，而不是让工作流隐藏在私人的编程会话中。

Tan 将一些个人机器人留在 Slack 之外，而让工程机器人加入共享线程。Ugarte 说，目标是让机器人在现有企业工具中工作，包括文档和会议，而不是重新构建所有商业软件。

展望未来，Tan 设想机器人拥有更多自己的身份和工具。她对让人更顺畅地向智能体表达意图的界面感兴趣，不过她举出的例子是可能性，而不是产品承诺。

Ugarte 说，软件拥有其他知识工作常常缺少的基础设施：代码可以编译、测试，大部分上下文存在代码库里。而其他领域的重要信息可能藏在人们的头脑或分散的文档中。

主持人讨论围绕 AI 组织的公司如何分配结果责任并教员工使用智能体。Ugarte 预计，随着执行成本下降，定义目标和决定如何衡量目标会变得更加重要。

Tan 说，最小而有用的工程循环，是让智能体能够像用户一样运行代码并检查结果。它可以发现问题、修改代码并重复，直到达到明确目标。

她区分了功能正确性与整体质量：循环可能让功能完成要求，却仍然存在性能或资源使用问题。工程师仍需设计环境和约束，引导智能体做好工作。

基本循环可靠后，一条告警可以触发智能体复现问题、检查应用并提出修复。Tan 说，她还使用协调智能体管理子智能体，而不是亲自监督每一步。

一位主持人问，当彻底的自动代码审查消耗数千万 token 时，审查多少才够。Tan 说审查仍有价值，但她减少了部分对抗式审查，因为智能体可能在不理解产品整体目标的情况下过度迎合反馈。

她的替代办法是把更多知识放进架构、API、编译器和静态检查中。写进代码库的规则能防止反复出现的错误，无须每次都花费 token 让智能体重新发现。

Tan 用 Electron 桌面应用举例：依赖检查器禁止分配给主线程与渲染线程的部分互相导入。它不测量执行时间，而是通过边界约束，尽量避免重任务阻塞渲染线程。

她说这条规则帮助应用保持稳定的性能。关键基础设施和数据库变更仍可能需要人类参与；审查程度应取决于工作内容及其后果。

Tan 提到自己可以使用大量模型资源，并把自己的工作流当作探索未来工程方式的实验。她认为，设计良好的代码库检查可以让普通智能体辅助工作更经济。

Ugarte 说，团队的瓶颈越来越多地变成对产品方向达成共识，而非编写功能所需的时间。许多想法已经有拉取请求，但全部合并会让产品变得零散。

Tan 的反馈机器人收集用户报告，能够复现并修复部分小错误。团队对核心界面变更采取不同做法：内部使用更长时间，对没有获得强烈内部支持的改动选择不发布。

Tan 将自己的软件工厂主要用于维护、性能和用户报告的问题，而不是自主决定新功能。这让工程师有更多精力关注产品体验，以及决定应该构建什么。

Tan 学习过会计和金融，发现自己喜欢构建电子表格模型和宏。经历一次早期创业并参与澳大利亚创业社区后，她获得了第一份技术工作。

她说，在网上分享学习内容后，有人邀请她在 Ember 大会上演讲，尽管她害怕公开发言。导师的帮助和传达想法的能力，让她得以继续成长为工程师。