团队落地 Agent 工程化 Loop 的一些必看小技巧
实现 Agent 工程化的团队协作，必须将个人助手能力转化为集体力量，核心在于打造完整的上下文循环。通过 Grilling 明确需求边界、用 Context 取代 Control 指导方向，最终实现经验沉淀与团队复用。
Agent 编程真正的差异已超越提示词技巧。关键在于上下文如何融入任务、任务如何自我验证、长程执行如何持续修正，以及这些经验如何被团队和后续 Agent 复用。
若仅仅把 Agent 看作个人窗口中的助手，它确实能提升效率。但它越是好用，问题就越突出：判断、踩坑、取舍、验证方式，全都封锁在一个人的会话里。下一位同事看不到，下一个 Agent 也无法获取。要让 Agent 从“替我干活”进化为“为团队积累能力”，需要一条完整的 Context Loop。
Context Intake：先问清楚，而不是先写 Spec
图：从需求澄清、工程反馈到团队 Wiki 的 Context Loop 总览
许多团队最初寄希望于 Spec Coding：先撰写 Proposal、Design、Tasks，再交给 Agent 执行。这种做法看似稳定，实则存在两个硬伤。
第一，Spec 很快会过期。代码仓库在变化、接口在调整、同事的提交在更新。Agent 若拿着几天前的文档继续执行，其中的假设可能已经失效。对于工程任务，代码和真实运行结果才是 source of truth。
第二，Spec 容易制造错觉：文档写完了，交付就会自动发生。但实际上，Agent 常卡住的地方是状态应放何处、已有接口能否复用、失败后如何恢复、验收标准是否真正通过。这些问题不是靠更长的模板能解决的。
更有效的入口是 Grilling。它并非让 Agent 先产出一大篇设计再找缺口，而是在写文档之前就把问题问穿：
- 这个需求到底解决什么问题？
- 哪些边界绝对不能碰？
- 有没有现成模块可以复用？
- 什么状态算完成，什么状态只能算“看起来能跑”？
- 如果失败，用户现场怎么保住？
产物不需要厚重。通常一份薄薄的 Context & ADR 就足够：目标、验收标准、关键决策、已排除方案。施工路径不必写死，留给 Agent 在代码和反馈中自行调整。
Context over Control：别把 Agent 关进选项题
提供上下文并不等于控制每一步。许多 Agent 习惯性地抛出选择题：A 方案、B 方案、C 方案。低风险分支这样做问题不大，但方向性判断一旦被压成选项，错误假设就会混入其中。
例如，“登录态过期怎么处理”，答案不应只是“跳转登录页/弹窗/静默刷新”。真正重要的上下文可能是：不能丢失用户正在编辑的内容；token 过期、权限不足、网络失败要分开处理；刷新失败后要保留现场，并且能恢复。这个判断无法塞进 ABC。
可以在 AGENTS.md 或 CLAUDE.md 里写一条简单规则：
涉及产品方向、架构边界、数据一致性、权限和恢复策略时，不要只给选择题。
先用文字说明你的判断、假设和不确定点，再和人讨论。
低风险实现细节可以给选项。这条规则的核心并非礼貌，而是避免上下文被 Agent 的选项提前裁剪。
另一个实用的输入技巧是语音。打字会让人天然压缩信息，许多背景、担心和反例写着写着就被省略了。语音输入反而容易把真实动机和边界条件讲出来，再让输入法或 Agent 整理成结构化文本。对 Agent 而言，这些“碎碎念”常常比一份工整的 PRD 更有价值。
Prototype Handoff：体验问题先做出来看
交互体验、状态流转、信息架构这类问题，通过文字讨论到一定程度就会失真。最省时间的做法不是继续讨论，而是让 Agent 做一个低保真 prototype。
更稳妥的方式是把探索会话和主会话隔离开：
图：主会话、探索会话和人工反馈之间的 prototype handoff 链路
隔离的好处很明显。主会话不会被试错过程污染，探索会话也无需背负完整历史包袱。体验完后将结论写回主线即可。对复杂交互来说，这比在一个长会话里反复描述“感觉不对”要可靠得多。
Harness：Loop 能跑多远，取决于反馈多硬
图：测试、CI、视觉回归等硬反馈让 Agent 能围绕目标持续修正
上下文聊清楚后，还得让 Agent 知道自己的对错。这里的 Harness 并非抽象概念，而是测试、CI、lint、类型检查、截图回归、溢出检测这些工程反馈。
提示词和 Skill 有用，但它们是概率性的。上下文一长，模型可能遗忘；注意力一分散，规则可能被覆盖。lint 和 test 则不同，它们每次都会触发。更重要的是，报错本身是最精准的提示：哪一行错了，为什么错，怎么改，全部包含在反馈里。
如果某条提示词被反复书写、反复强调，通常说明它不该继续待在提示词中，而应下沉到 Harness。
| 反馈层 | Agent 能闭环到哪里 | 典型做法 |
|---|---|---|
| 编译检查 | 至少保证项目能构建 | tsc、go test、构建脚本 |
| Lint / 类型规则 | 把重复性规范变成硬约束 | ESLint、自定义 rule、静态检查 |
| 单元测试 | 验证业务逻辑没有跑偏 | 关键分支、边界条件、错误恢复 |
| 集成测试 | 验证模块之间能连起来 | API、状态流、权限链路 |
| 视觉回归 | 验证页面没有被改坏 | Playwright 截图对比、溢出检测 |
有多少 Harness，就能放心让 Agent Loop 到多远。只有编译检查，就让它 Loop 到编译通过；有单测，就让它 Loop 到逻辑正确；有视觉回归，才敢让它自行调整布局和动效。
Goal Loop：让 Agent 围绕目标自己转起来
复杂任务通常不是一次修改就能结束。实现、测试、失败、修复、再测试，这本来就是一个循环。如果每一步都要人盯着，Agent 再快也会被人卡住。
一个可执行的 /goal 指令需要三件事：目标、退出条件、验证方式。
/goal
让移动端页面在 iPhone 14 尺寸下不出现横向溢出。
退出条件：
- Playwright 截图对比通过
- 控制台无 layout 相关错误
- 修改不影响桌面端关键布局
验证方式：
- 运行 `npm run test:visual`
- 如果失败，阅读失败截图和 diff，继续修到通过这类 Loop 的边界要清晰。它适合有明确反馈的小任务，不适合一开始就丢出巨大目标。没有 Harness 的 Loop 只是自动化试错，烧 token，不一定产出稳定结果。
自动化任务也可以按这个思路设计。例如，每天早上扫描昨天的 CI 失败，能修的自动修复，修不了的汇总；每周整理一次团队 Wiki，把看板、文档和讨论中的新知识炼化进去。关键仍然是反馈闭环，而非定时任务本身。
Long Task Runtime：长程任务别塞进一个会话
短任务可以在一个会话中 Loop。任务一长，问题会集体爆发：目标漂移、反复尝试同一错误方案、测试反馈在上下文压缩后丢失、token 开销快速膨胀。根因不是窗口不够大，而是单个会话承载了过多职责。
处理长程任务有三种常见手段。
| 手段 | 解决的问题 | 注意点 |
|---|---|---|
| 大需求拆解 | 控制单次 Loop 的复杂度 | 子需求要能独立验收，不能碎成无意义任务 |
| 运行时编排 | 并行推进互不依赖的工作 | 用 git worktree、Sub Agent 或脚本编排隔离上下文 |
| 状态外置 | 防止会话压缩后丢掉关键决策 | 用薄 Context + ADR 记录目标、边界、已排除方案 |
Sub Agent 编排时，主会话最容易犯的错是忍不住抢活。Worker 沉默一会儿，Main Agent 就想 kill 掉重来，或者自己接手继续。更好的协议是：Main Agent 只定义目标、输入、验收标准和返回格式；Worker 不报告 blocked、不要求人介入、不明确失败，就不要打断。
状态外置也很关键。传统 Spec 一旦太厚，重新加载时会占据上下文窗口中最宝贵的区域。薄 Context 文件只记录高密度信息：目标、验收、架构决策、排除方案。其余细节让 Agent 从代码中读取。能从代码推导出来的，不必再写一遍。
Team Loop：把 Agent 的工作现场公开出来
个人 Agent 跑顺之后，团队层面的瓶颈会变成可见性。
需求讨论过什么，Agent 问过什么，哪个方案被排除，为什么最后选了这个实现，这些信息如果只在个人会话里存在，就会形成知识孤岛。公开工作现场的思路，是把 Agent 放进团队已在使用的场所：群聊、话题、会议、看板。
需求还没定型时，就让产品、设计、研发、QA 和 Agent 在同一个公开空间里打磨。Agent 如果连着代码仓库、历史文档和设计稿，它可能比任何单个人的上下文都完整。它问出的“仓库里是不是已有类似接口”或“这个状态和现有权限模型冲突”，能提前暴露问题。
会议也一样。逐字稿不是给人逐行读的，而是给 Agent 读的。智能摘要会抹掉争论、犹豫、未决分歧，而恰好这些细节对后续判断最有价值。录制和逐字稿如果能进入后续检索链路，下一轮 Agent 就不用从“大家当时为什么这么定”开始猜测。
看板是另一个入口。让 Agent 像人一样出现在任务面板上，有身份、有进度、有审计，能领取任务、汇报 blocker、留下决策过程。这个问题的重点不是“Agent 怎么互相聊天”，而是团队如何管理 Agent 的工作状态。
共享 Agent 还会带来权限隔离问题。多人在群里 @ 同一个 Agent，它到底用谁的身份？访问谁的仓库权限？授权缓存会不会串？比较稳妥的做法是做 per-user 目录、工具 wrapper 注入身份环境变量，再加授权 preflight：先确认用户身份，再确认工具鉴权，最后确认资源权限。正常路径下不能使用户 A 的授权被用户 B 的任务误用。
LLM Wiki：让下一轮 Agent 不从零开始
图：原始素材、编译层 Wiki 和治理规则共同支撑下一轮 Agent 召回
公开现场解决的是“过程可见”，LLM Wiki 解决的是“经验可复用”。
它不是资料仓库，也不是将所有聊天记录塞进向量库。更合理的结构是三层：
raw/sources/ 原始素材，不可变，用来追溯事实来源
wiki/ 编译层，沉淀概念、对比、经验和综合判断
governance/ 规则层，放 purpose、schema、AGENTS 等约束为什么不用 Agent 自带的长期记忆？自动积累的 memory 时间久了会变脏：噪声多、来源不清、适用范围不明，Agent 还可能将其作为可靠前提。Wiki 的价值在于经过筛选和维护，能追溯来源，也能标注过期和矛盾。
为什么不只靠 RAG？群聊、飞书文档、Bug 单、Git history 分散在各处，现场检索容易召回碎片。某条群消息可能是错的，正确结论藏在另一个 Bug 单评论里。Wiki 是提前做过整理、交叉验证和时间线对齐的结果，Agent 读到的不是某个人某一刻的观点，而是一份经过清理的判断。
维护也不该靠每次任务结束时顺手写。那样会侵占主任务注意力，而且当前会话视野有限，容易沉淀错误信息。更稳妥的是独立自动化：每天或每周扫描看板 issue、历史会话、文档和代码提交，将有持久价值的内容更新进 Wiki。已有页面就补强，不要动不动新建重复条目。
分层规则可以很简单：
- AGENTS.md 放每次必须遵守、违反就会出错的规则。
- wiki/ 放有持久价值、但不是每次都要加载的经验。
- 临时 Context 任务完成后可以删，不要让短期状态污染长期知识。
- 代码能表达的，不重复写进 Wiki。
消费方式也有两种。Agent 开工前自动查 Wiki，按 index 和 schema 找相关页面，不全量加载。人想了解某个主题时，也可以直接让 Agent 查 Wiki，甚至现场生成一个 HTML 讲解页。几百个 Markdown 文件靠人翻阅没有意义，靠 Agent 导航才是它应有的用法。
Eval：召回有没有用，要能测
Wiki 并非越厚越好。它有没有用，最终要看 Agent 的表现是否改善。
可以从 10 到 20 个历史 issue 做私有评测集，优先选那些“第一次失败是因为缺少历史知识”的案例。对比两组执行：不开 Wiki 召回、开启 Wiki 召回。观测三个点就够：
- Agent 有没有主动去查 Wiki。
- 查到的内容是不是对的。
- 最终结果有没有变好。
小样本足够看出早期信号。比起追求一套大而全的评测系统，先把“历史知识有没有帮到当前任务”测出来更重要。
一条更现实的 Agent 工程链路
Context Loop 可以浓缩为一句话：需求靠共同打磨，质量靠 Harness，交付靠 Loop，经验靠 Wiki 复利。
这不是某个工具或提示词能单独解决的问题。Grilling 负责把目标问清楚，Harness 负责让反馈变硬，Loop 负责让 Agent 自己修到通过，Runtime 编排负责撑住长程任务，公开现场和 Wiki 负责把个人会话里的知识释放出来。
Agent 的能力越强，人类越应将精力集中在关键判断而非细节执行。通过 Grilling 引出目标、Harness 验证结果、Wiki 传承经验，人类的价值始终在于辨别方向与做出决策。