论文上个月底贴到 arXiv 上（编号 2608.30701），说大模型编程助手参与开发这件事，可以切成四个阶段来管：前期人工审查多一些，开发产物越成熟，给智能体的自主委托越多。这是一次从 Infobip 团队实践经验里提炼出来的行业报告，两页，要收录在 CIKM '26 论文集里。主张本身不难读，但“切成阶段”四个字往代码方向落一下，会发现它真正在管的东西不是那个数字，是上下文。
这篇我们动手把四阶段工作流塞进一个最小状态机，不为了复刻论文，只把阶段转移和上下文入口这两个最核心的机制立起来，跑一遍。跑完你会发现它自己承认的两个开放问题，不是纸上客气，是它这个骨架真的会在那两个位置裂开。
先把最朴素的版本写出来。状态机只有一个状态：当前阶段；一个转移动作：人工审查通过，新产物入库，阶段往前走一格。
class PhasedWorkflow:
def __init__(self):
self.phase = 0 # 0..3，四个阶段
self.artifacts = [] # 已通过审查的产物
def advance(self, artifact):
# 所有产物进入下一阶段前，必须经过人工审查
if not human_review(artifact, self.phase):
return False
self.artifacts.append(artifact)
self.phase = min(3, self.phase + 1)
self.human_budget *= 0.8 # 示意：后期人力投入递减
return True
human_review 我故意不写完整实现，它取决于每个团队的评审表。这个骨架能跑的部分就这些：阶段在走，人力投入在降，代理自主权在升。跑一遍正常情形，阶段 0 的产出通过审查，阶段进 1；阶段 1 的产出通过，阶段进 2；阶段 2 的产出通过，阶段进 3。按这个示意因子算，走到末端，人工审查的强度大约掉到四成。到这一步就清楚了：所谓“前期投入更多人工审查”，在实现上就是一个随阶段递减的通过阈值；所谓“逐步增加自主委托”，就是这个阈值在降。
但真正值得往下挖的，不是这个阈值降不降，是阶段之间切的那一刀在代码里靠什么信号。论文说“研究与规划阶段的上游错误会在后续阶段累积放大”——这句话得变成代码才看得出分量。我写一段示意执行轨迹，看看一个上游错误在不被拦截的时候怎么走。
# 示意：研究阶段把一个有歧义的需求当成已确认前提入库
artifacts.append(Requirement("file upload", missing=["size limit"])) # 缺 size limit
# 规划阶段把这个需求直接喂给 agent 做任务分解
plan = agent.plan_round(artifacts[-1]) # 拆出来的任务也缺同一条
# 代码生成阶段照着这个计划产出，缺 size limit 变成运行时异常
code = agent.code_round(plan) # 生成了没有边界检查的上传模块
这段是示意，不是论文数据。论文原话只说上游错误会累积放大、直接改生成代码会引入冗余和脆弱性。我把它摊成轨迹，是想看那个“放大”在机制上是怎么发生的：不是错误本身变大了，是后面每个阶段都把它当已确认的输入。于是错误从一处需求描述，长成三段各自独立但互相呼应的坏产出。到这一步，人工审查前置的理由就清楚了：最便宜的时候是它还在需求那一格的时候。
回到论文本身。它作为一份两页行业报告，把四个阶段和四种应对已知失败模式的策略摆了出来，但没有给完整实现。我们假设它是一个“真实版本”，去翻它多做了什么、没做什么。多做的部分是，它没停在“分阶段”这个口号上，它直接把上下文管理单独拎出来当核心问题，并且配了四种策略。没做的部分，作者自己写在末尾：两个开放问题。一个是缺少衡量工作流有效性的指标，另一个是形式化上下文管理组件与实际所需的工作流模式之间存在差距。
我读下来更在意的是第二个。不是因为“衡量指标”不重要，而是它更接近机制。你脑子里有个工作流，你手上的上下文管理组件是另一套形状，这两套东西对不上。前一个开放问题是“你没法给整个系统打分”，后一个是你连“当前该把哪些东西放进上下文”这个动作都还没有一个可靠的形式描述。前者是仪表盘缺图标，后者是方向盘和轮子之间虚位太大。
这里要停一下，把“差距”这个词铺开。论文说它那四种策略是“在每个阶段用于应对已知失败模式”的。这句话反过来说，就是这些策略是给已知失败模式打的补丁，不是一个从上下文预算、信息熵、依赖图这些第一性概念推出来的模型。补丁能拦住你见过的坑，拦不住你还没见过的工作流形状。这就是为什么作者说“形式化上下文管理组件与实际所需的工作流模式之间存在差距”。我一开始也以为既然都到了“形式化”这一步，差距不会太大。细想下来，它说的“形式化”只是把上下文管理写成了一个组件，不是把上下文本身建模清楚。
往下挖一层。四阶段工作流在机制上到底是什么？它把一个没有内置刹车的采样循环——采样，调工具，结果塞回上下文，再采样——在时间轴上切了四刀，让人工审查在每刀之间强行介入。前期介入，是因为上游产物还便宜、改起来代价低。后期放权，是因为产物已经变沉，人工逐行审的收益降下来。但“四个阶段”这个数本身不是机制，是一个经验分法。换成三阶段、五阶段，刹车点和介入强度会变，核心不会变——核心是你得在这个循环里人工装止损点，因为这个循环自己没有。作者管它叫“管理”，其实就是给循环加状态护栏。
所以说到底，这篇论文真正说干净的一件事，不是四个阶段这个切法，而是上下文管理在 agent 辅助开发里是一等公民。四阶段只是它为了把这件事摊开而铺的一个台面。作者留下的第二个开放问题，本质是在说，这个台面和它要放的上下文管理机制之间，还有一块没填上的地。
想往下再挖一层，我留一个练习。你自己实现一个四阶段状态机，但把阶段转移的判定条件，从“刚才哪个阶段的输出过没过审”，改成“这个阶段的产物要喂给下一阶段时，该替换上下文中哪些旧产物”。写一个最小的上下文窗口，固定 token 预算就好，不用真跑模型。跑三次需求变更，每次都允许人工审查否决。你会发现：阶段回退，就是审查不通过时状态机要支持反向转移，不会是一个只往前推的流水线。我的第一版只写了 phase = min(3, phase+1)，连 phase -= 1 都没有——那是一个很关键但容易漏的实现细节。真实工作流里，研究结论在代码生成阶段被推翻、又回到规划阶段重来一遍，发生得比论文那个单向箭头暗示的次数多得多。补上这个，再回去看“形式化上下文管理组件与实际所需的工作流模式之间存在差距”，可能就不觉得它是一句收尾套话，而是你刚刚写代码时卡住的那个位置。