Amp 平台最近上线了一个新角色：服务账号（Service Accounts）。与绑定特定用户名的个人账号不同，服务账号归属于整个工作区，不隶属于某一位具体成员。这种设计解决了团队共用 AI 能力时的归属权问题。
只有工作区管理员有权限创建服务账号。每个服务账号拥有独立的 API 密钥和第三方凭证。当某个线程由服务账号生成时，同工作区的其他成员都能查看并参与交互。这种线程是多人协作模式，任何成员都可以向其中发送消息或调整方向。
你可能感兴趣：未命名文章
由于工作区内任何人都能驱动服务账号的线程，分配凭证时需格外谨慎。建议只授予那些愿意分享给所有团队成员的权限避免个人敏感数据泄露给整个团队。
适用场景分析
凡是属于团队公共责任的工作，都适合放在服务账号下运行。比如设置了自动化流程的线程，即使创建者休假，其他成员也能随时介入处理，保证业务不中断。
代码审查与维护
检查每个 Pull Request 或保持文档准确性，是团队共同的任务，不应由单个用户独占。让服务账号承担这类工作后，团队成员可以进入线程，共同决定代码或文档的修改方向。
在 Puck 中设置这类流程时，可以这样表述需求：
- 触发全工作区范围的自动审查：提示 Puck 设置监听器，当新的 GitHub PR 进入时自动启动审查流程，并明确指定这些审查线程由整个团队而非个人所有。
- 定期扫描公开文档：要求 Puck 开启一个工作区所有的线程，每隔 24 小时检查一次公开文档的时效性，发现过时内容时直接@相关负责人做更新。
这些重复性、持续性的维护工作通过服务账号管理，确保了任务连续性和团队协同性。
程序化调用与 CI 集成
对于由脚本触发的自动化工作，比如说 CI 构建失败时通过 amp -ox 命令生成线程，使用服务账号的 API 密钥至关重要。这样，生成的线程归属服务于团队，而不是归属于配置流水线的个人。
一个典型的 CI 集成示比如说下：
- CI 中的自动审查机器人：在构建脚本中，如果测试失败，调用 amp 命令并传入服务账号的密钥，询问 AI 这是真实回归错误还是不稳定的测试用例。这种程序化调用方式确保了 AI 助手的工作记录归属于团队资产，而非个人私有数据。
