RPI 工作流：像资深工程师一样使唤 Agent
上周带一个新同事上手 AI Coding，看他操作了十分钟我就知道问题在哪了：一个窗口从头聊到尾。调研、讨论、写码、调试、返工，全在一个会话里滚，四十多轮之后窗口里是一锅粥，模型的输出质量随粥的浓度稳定下降，他的解决方式是骂骂咧咧地继续追加澄清——粥更稠了。
我没给他讲上下文工程的大道理，只给了他一个足够简单的起手式：RPI——Research、Plan、Implement，三步，三个独立会话，每步一条铁律。一周后他自己跑来说返工少了一半。这个方法出自 HumanLayer，简单到一张便签能写下，但每条铁律背后都有讲究，值得写一篇。
R：只许看，不许动
第一个会话只做一件事：让 Agent 探索。给它问题陈述，让它摸清代码库结构、相关模块、已有的类似实现，最后产出一份调研纪要——落盘成文件，不是留在对话里。
铁律：这个阶段不允许采取任何行动。不写代码、不改文件、不装依赖。
为什么要这么绝对？因为模型有强烈的动手欲——你说「看看这个 bug」，它三分钟后已经提交修复了。而跳过理解的修复，命中根因靠运气，多数时候是在给症状打补丁。我自己的血泪版本：早期有次让它「看看为什么定时任务偶尔不执行」，它看了两个文件就动手加了个重试。重试当然「有效」——症状被掩盖了，真正的原因（时区处理错误导致的调度漂移）又活了两个月。
从那以后我的 R 阶段提示词里永远有一句：「只调查，不修复，输出调研纪要。」
P：人类判断力的主战场
第二个会话（或者接着第一个），让 Agent 基于调研纪要写出执行计划：改哪些文件、什么顺序、每步怎么验证。然后——重点来了——人来审。
这是整个流程里人类时间投入产出比最高的一环，道理很朴素：计划里的错误此刻还是文字，改起来是几句话的事；放进实现阶段就变成散落在十几个文件里的代码，改起来是一次返工。同一个错误，在 P 阶段修和在 I 阶段修，成本差一个数量级。
铁律：在这一步偷懒，代价在后面成倍偿还。
审什么？我给那位同事的清单只有三条，够用：
- 顺序：高风险、可能被推翻的决策（数据模型、接口）是不是排在最前面
- 边界：有没有混进「顺手优化」的 scope 蔓延苗头
- 验证：每一步做完拿什么证明是对的
审计划平均花我五到十分钟。这五到十分钟是我全天杠杆最高的工作时间，没有之一。
I：新窗口，轻装上阵
第三步，开新窗口执行批准后的计划。输入只有两样：计划文件 + 相关文件的引用。
为什么必须新窗口？R 阶段积累了大量探索噪声——读过的几十个文件、被否决的猜测、绕过的弯路。这些东西对执行不仅无用，还在稀释注意力。计划本身已经是调研成果的浓缩，带着计划轻装上阵，比拖着全部探索历史干活稳定得多。这是 RPI 里最反直觉也最见效的一条：信息不是越多越好，是越干净越好。
任务大就在 I 阶段内继续拆子任务、各起会话，子代理那篇讲过，不重复。
三份产物的文件约定
RPI 跑顺之后，我们把三个阶段的产物固定成了文件约定，放在仓库的 .work/ 目录下（gitignore 掉，纯工作区）：
.work/
research-<任务名>.md R 阶段产出：相关文件清单、现有约定、
可选路径及各自代价、待确认的问题
plan-<任务名>.md P 阶段产出：步骤清单，每步含改动范围
和验证方式；头部有一行「已批准/待审」
notes-<任务名>.md I 阶段产出：执行中的决策记录和偏差
这个约定带来两个当初没预料到的好处。一是中断恢复：执行到一半被会议打断、或者窗口爆了，新会话读这三个文件就能原地续上，不用从头交代背景。二是复盘材料：出问题回溯时，「当时调研到了什么、计划是什么、实际偏离了哪」全有据可查。以前这些信息散在对话历史里，会话一关就蒸发了。
另外一个细节：plan 文件头部那行「已批准/待审」状态标记不是摆设。我们给 I 阶段的提示词里写死了一条——计划文件状态不是「已批准」就拒绝执行。很轻的一个机制，防的是手滑跳过人工审查那一步。跑了两个月，这条规则拦下过三次「我看计划差不多就直接跑了」的侥幸，每次事后看计划里都真有该改的东西。
它专治什么病
回头说那位同事的「一锅粥」，其实是两个坏习惯的复合体，RPI 每一步都在精准拆解：
「一窗到底」被「阶段切窗口」拆掉——每个阶段的产物落盘成文件，窗口用完即弃，信息靠文件传递而不是靠对话历史堆积。
「拿到任务就动手」被 R 和 P 的强制顺序拆掉。这条其实和 AI 无关——资深工程师之所以资深，恰恰在于拿到任务后不立刻写代码。模型给了所有人「说一句就动手」的能力，这个能力本身在诱导坏流程。工具变了,纪律没变，只是纪律的执行对象从自己的手变成了 Agent 的手。
要说 RPI 的局限也有：对五分钟能搞定的小改动，三个会话纯属仪式感，直接干就行。我的分界线大概是「一眼看不出要改哪几个文件」——达到这个复杂度，就值得走全流程。介于两者之间的模糊地带，我的偷懒版是「R 和 P 合并成一个会话、I 单独开」——保住「执行会话必须干净」这条底线，前面松一点问题不大。实践里真正不能省的其实就两样：P 的人工审查，和 I 的新窗口。
另外提醒一句：R 阶段的调研纪要别追求完备。它的角色是「够 P 用」，不是代码库百科——我见过有人让 R 阶段跑一个小时输出五千字，P 阶段根本消化不了。调研纪要超过一屏，多数时候说明问题陈述给得太模糊，该回头改问题，不是继续堆调研。
方法论最怕听完点头、回去照旧。所以结尾就一个建议：明天挑一个中等复杂度的任务，严格走一遍 R、P、I，产物落盘。跑完拿返工次数和你平时的做法比——数据会替我说话。