团队要实现Agent工程化，核心目标就是：如何将“个人助手”的效能放大为整个团队的“协同智能”。听起来似乎很抽象，但拆解开来，无非是几个关键环节。一旦掌握了这套打法，你会发现许多之前卡在瓶颈上的问题会迎刃而解。

说到Agent编程，真正的差距早已不在于“是否会写提示词”。更关键的是：上下文如何进入任务，任务如何自我验证，长程执行中如何持续修正，以及这些经验如何被团队和后续的Agent继续复用。

如果只把Agent当成个人窗口中的工具助手，它确实能提升效率。但它越好用，问题也越突出：判断、踩坑、取舍、验证方式，全都锁在个人会话中。下一位同事看不到，下一个Agent也拿不到。要让Agent从“帮我干活”变成“帮团队积累能力”，就需要构建一条完整的Context Loop（上下文循环）。

Context Intake：先深度追问，而不是先写文档

图：从需求澄清、工程反馈到团队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。

有多少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开销快速膨胀。根因不是窗口不够大，而是单个会话承载了太多职责。

处理长程任务有三种常见手段。

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传下去，但判断本身还得有人负责。