团队落地 Agent 工程化 Loop 的一些必看小技巧！

原文链接：AI 小老六

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 做私有评测集，优先选那些“第一次失败是因为缺少历史知识”的 case。对比两组执行：不开 Wiki 召回、开启 Wiki 召回。观测三个点就够：

Agent 有没有主动去查 Wiki。
查到的内容是不是对的。
最终结果有没有变好。

小样本足够看早期信号。比起追求一套大而全的评测系统，先把“历史知识有没有帮到当前任务”测出来更重要。

一条更现实的 Agent 工程链路

Context Loop 可以压成一句话：需求靠共同打磨，质量靠 Harness，交付靠 Loop，经验靠 Wiki 复利。

这不是某个工具或提示词能单独解决的事。Grilling 负责把目标问清楚，Harness 负责把反馈变硬，Loop 负责让 Agent 自己修到通过，Runtime 编排负责撑住长程任务，公开现场和 Wiki 负责把个人会话里的知识释放出来。

Agent 越能干，人越不该把时间花在盯每一步执行上。人的价值会更集中在判断：什么值得做，什么不能碰，什么才算做对。这个判断可以被 Grilling 引出，被 Harness 验证，被 Wiki 传下去，但判断本身还得有人负责。

AI小老六