03｜如果把 loopat 放进团队：我会先定这 6 条协作规则
系列：loopat 三篇实践笔记
上一篇：[02｜拆 loopat 架构：Loop、Sandbox、Vault 到底解决了什么]
第一篇：[01｜我蹲了一下 loopat：它不是又一个 Agent，而是把上下文当成工作区来管]
这一篇聊落地：如果真把 loopat 放进一个工程团队，我不会先忙着装，而是先把规则定好。
一、工具不是最难的，团队规则才是
前两篇聊完 loopat 的定位和架构，我脑子里一直有个判断：
它不是个人效率工具那么简单。
一个人用，最多是本地多一个 AI 工作区；团队用，它会直接碰到协作、权限、知识沉淀、代码提交这些硬问题。
这类工具最怕什么？不是跑不起来，而是跑起来以后没人管：
- Agent 随便开 Loop
- memory 里塞满垃圾
- knowledge 没人 review
- vault 权限越给越大
- AI 提交的代码不知道谁负责
- 聊天线程变成新垃圾场
所以如果我把 loopat 放进团队，第一件事不是 npx loopat，而是先定规则。
二、规则 1：不是所有聊天都能 Spawn Loop
loopat 很吸引人的点是：可以从聊天线程启动 Loop。
但这能力不能乱开。
我会规定：只有三类线程可以创建 Loop：
- 明确任务型：有目标、有交付物，比如"修复支付回调重试 bug"。
- 明确调查型：有现象、有范围，比如"排查昨晚 API P95 升高"。
- 明确沉淀型：有结论、有复用价值，比如"整理新版发布 checklist"。
闲聊、争论、脑暴，不能直接 spawn。
每个 Loop 启动前，必须有一个简短 brief：
- 目标是什么
- 不做什么
- 交付物是什么
- 谁 review
- 允许访问哪些资源
这五行写不出来，就别开 Loop。
三、规则 2：Loop 必须有 Owner
AI 不能当责任人。
每个 Loop 必须绑定一个人类 Owner。这个人负责：
- 确认上下文是否够
- 决定是否继续跑
- review 结果
- 决定是否 promote 到 knowledge
- 对最终提交负责
我会把 Owner 写进 Loop 元数据里，而不是靠聊天里口头说。
loop:
title: "Investigate API latency spike"
owner: "@chen"
reviewer: "@li"
type: "investigation"
allowed_vault: "grafana-readonly"
promote_policy: "review-required"
这不是官僚。Agent 越强，责任边界越要清楚。
四、规则 3：Knowledge 必须 review，Memory 可以轻一点
loopat 把 Knowledge、Notes、Memory 分开，我会顺着这个分层定写入规则。
| 类型 | 谁能写 | 是否 review | 用途 |
|---|---|---|---|
| Knowledge | 人类 Owner 提交 | 必须 review | 团队长期知识 |
| Notes | Loop 自动生成 | 可事后整理 | 过程观察 |
| Memory | Agent / 人都可写 | 轻量抽查 | 偏好、路径、约定 |
最关键的是 Knowledge。
它一旦进团队知识库，就会影响后面所有人和 Agent。错一条，后面可能反复错。所以我会要求：Knowledge 走 PR，不直接写 main。
Notes 可以宽松一点。它是过程层，不一定长期正确。
Memory 更像便签，但也要定期清理。否则半年后 memory 会变成一锅陈年垃圾。
五、规则 4：Vault 默认只读，写权限单独申请
我最担心的不是 Agent 写错代码，而是 Agent 拿错权限。
loopat 有 per-loop vault，这很好。但团队落地时必须有默认策略：
- 默认给只读凭据
- 生产写权限默认不给
- 涉及部署、回滚、删数据，必须人工确认
- 每个 vault 都要有用途说明和过期时间
我会这样分：
| Vault | 权限 | 用途 |
|---|---|---|
grafana-readonly |
只读 | 查指标、日志 |
github-readonly |
只读 | 看 issue / PR |
github-write-dev |
写 dev 分支 | 自动提交草稿 PR |
prod-deploy |
高危 | 默认禁用，需要临时批准 |
AI 工具最容易让人松懈："反正只是调一下接口"。但在 SRE / DevOps 里，一个 token 就能滚掉半个集群。宁可麻烦，也别默认给大权限。
六、规则 5：每个 Loop 结束必须有收尾动作
会话结束不是结束。Loop 结束时必须做三件事：
我会强制生成一份 result.md：
# Result
## What changed
## Evidence
## Decisions made
## Follow-ups
## Should promote to knowledge?
这份结果比聊天记录重要。聊天记录是过程，result.md 才是可以给下一次 Loop 复用的资产。
七、规则 6：先在低风险场景试，不碰生产写操作
我不会一开始就让 loopat 参与生产修复。
第一批场景我会选这几个：
- 文档整理：把聊天线程整理成 runbook。
- 代码阅读：分析某个模块的调用链。
- 测试补齐：给已有函数补测试，提交草稿 PR。
- 故障复盘整理：根据日志和聊天生成 RCA 草稿。
这些场景共同特点：就算 Agent 做错了，也不会直接影响线上。
等团队习惯了 Loop、Owner、Vault、Knowledge PR 这套规则，再考虑更重的场景。
八、我会怎么做一个 2 周试点
如果让我真推，我会这样安排：
第 1-2 天：环境和权限
- 找一台专门机器部署 loopat
- 只接 Claude API Key
- 只配置只读 GitHub / Grafana 凭据
- 禁止生产写权限
第 3-5 天：选 3 个低风险 Loop
- 一个文档整理
- 一个代码阅读
- 一个测试补齐
观察：上下文是否真的少复制了？result.md 有没有价值？
第 2 周：团队协作试点
- 从真实聊天线程 spawn Loop
- 要求 Owner 和 Reviewer
- Knowledge 走 PR
- 复盘哪些 memory 有用、哪些是垃圾
试点结束只看三个指标：
| 指标 | 怎么判断 |
|---|---|
| 上下文搬运是否减少 | 人有没有少复制粘贴 |
| 结果是否可复用 | result.md / knowledge PR 有没有人用 |
| 权限是否可控 | vault 是否出现越权需求 |
如果这三项都过关，再谈扩容。
九、它适合什么团队
我觉得 loopat 适合这几类团队：
- 已经重度用 Claude Code / Cursor，但上下文经常散掉
- 团队知识主要靠聊天和口头传递
- 经常做跨文件、跨服务、跨文档的任务
- 重视自托管和数据归属
- 有能力维护一点基础设施
不适合：
- 纯个人轻量写代码
- 没有 Git 流程的小团队
- 不愿意管权限和知识库治理的团队
- 想开箱即用、不想碰 Linux / Docker / sandbox 的用户
十、总结：loopat 真正考验的是团队成熟度
写完三篇，我对 loopat 的判断更清楚了。
它不是一个"下载就变强"的工具。它更像一套工作方式：把一次 AI 会话，变成一个有上下文、有沙箱、有权限、有产出、有沉淀的 Loop。
这套方式一旦跑起来，会很有价值；但前提是团队愿意为它建立规则。
我的最终评价：
- 技术方向：很对
- 产品成熟度：还早
- 个人试用：可以
- 团队落地：要谨慎设计
- 最值得借鉴：Loop 边界、Context 分层、Vault 隔离、Knowledge PR
所以我不会说"所有团队都该用 loopat"。更准确的说法是：所有正在把 AI Agent 带进工程协作的团队，都该看一眼 loopat 的设计。
它提醒我们一件事：Agent 不是只需要更聪明，也需要一个更像样的工作现场。
本系列三篇：
- [01｜我蹲了一下 loopat：它不是又一个 Agent，而是把上下文当成工作区来管]
- [02｜拆 loopat 架构：Loop、Sandbox、Vault 到底解决了什么]
- [03｜如果把 loopat 放进团队：我会怎么设计协作规则]
