在日常的研发中，直接向大模型输入”帮我实现这个功能”或“修复这个 Bug”，往往会陷入“生成代码 -> 与原有需求方案偏差/技术方案偏差/编译报错 -> 修复偏差/修复报错 -> 完成本轮开发”的问题，如何能保证单轮对话AI的完成质量？这种问题的根源在于：缺少必要的上下文约束、缺乏明确的决策边界，以及模型在自审时难以克服的“确认偏误”（Confirmation Bias）。
本文将分享在设计AI 研发工作流（dev-workflow 与 bugfix-workflow）的一点小小心得。本文将重点讨论流程中的决策链构建、状态机约束、Agent 角色分工，以及为什么在复杂工程中必须引入主 Agent、独立 Agent 与 subAgent 协同作战。
一、为什么需要结构化工作流？
在复杂工程中，编写代码只是整个研发链路的末端。未理清需求背景与边界就直接编码，极易导致设计偏离。因此，我们的工作流划分为明确的几个阶段，每个阶段对应特定的角色与责任：
flowchart TD
Phase0[Phase 0: 背景分析] --> Phase1[Phase 1: 架构与方案]
Phase1 --> Phase2[Phase 2: 代码实现]
Phase2 --> Phase3[Phase 3: 独立审查]
Phase3 --> Phase4[Phase 4: 证据验证]
Phase4 --> Phase5[Phase 5: 交付与归档]
阶段与角色定义
二、状态机：用确定性对抗模型的随意性
大模型在长会话中极易产生“上下文漂移”——例如在未确认需求细节时就开始生成代码，或者在审查失败后盲目跳过修复。
为此，我们在工作流中引入了状态机与阻断机制（Checkpoint）：
stateDiagram-v2
[*] --> ContextAnalysis
ContextAnalysis --> BackgroundPending: 背景梳理完成
BackgroundPending --> Planning: 背景审批通过
BackgroundPending --> ContextAnalysis: 补充背景
Planning --> ProposalPending: 方案与验收标准完成
ProposalPending --> Coding: 方案审批通过 (Approval)
ProposalPending --> Planning: 修订方案
Coding --> ImplementationPending: 实现与静态检查完成
ImplementationPending --> Reviewing: 实现验证与放行
ImplementationPending --> Coding: 实现反馈
Reviewing --> ReviewFixing: 审查未通过 (带证据列表)
ReviewFixing --> Reviewing: 定点修复后复核
Reviewing --> Testing: 独立审查通过
Testing --> VerificationFixing: 验证发现问题
VerificationFixing --> Testing: 定点修复后复验
Testing --> Delivery: 已执行检查通过，待人工项已披露
Delivery --> [*]: 汇总交付与归档
阻断机制的三条硬性规则：
- 关键决策分别放行：背景、方案、实现分别对应 Checkpoint #0、#1、#2。背景确认后才能规划，方案确认后才能编码，实现结果经验证与放行后才能进入独立审查。每次放行只推进当前关卡可以合法的进入下一阶段。
- 审查与验证失败次数上限：Phase 3 与 Phase 4 分别记录连续失败次数，达到 3 次时强制暂停，交由人类工程师干预；返修不重置次数，防止模型进入无限自我修补死循环。
- 证据驱动的可靠交付：进入交付阶段前，必须给出实际执行的静态检查、可用日志、截图或其他验证证据，并逐条标明验收状态。仍需编译、运行或真机确认的项目必须明确列出，不得以主观描述或静态结果代替运行结论。
三、深入理解多 Agent 架构：主 Agent、独立 Agent 与 SubAgent 的协同哲学
在 AI 工作流的演进中，单 Agent 的局限性日益凸显：当任务变得宏大、上下文变得冗长时，单一上下文中的模型会面临注意力分散、逻辑混淆和严重的确认偏误。因此，引入多 Agent 协同架构势在必行。
但在实践中，我们必须明确区分它们的职责与存在价值：
1.什么是主 Agent (Main Agent)？
- 角色定位：整个任务的“项目经理”与“核心主脑”。
- 职责与使命：
- 负责掌控总体进度、维护核心上下文（如原始需求、架构方案、主交付物）。
- 驱动状态机从 Phase 0 稳步流转至 Phase 5。
- 统筹全局，根据需要向外分派子任务，并对子 Agent 提交的结果进行汇总、核实与仲裁。
- 为什么不可或缺：没有主 Agent，任务会陷入群龙无首的碎片化状态；它是保障整条研发流水线逻辑连贯的唯一锚点。
2.什么是独立 Agent（如独立 Reviewer Agent）？
- 角色定位：拥有独立任务上下文的“外部专家”。
- 为什么需要它（打破确认偏误）：
- 在传统的单 Agent 模式下，写代码的 Agent 和审查代码的 Agent 是同一个。当它“自己审自己”时，由于历史上下文里充满了“我刚才是这样想的”、“这个逻辑我觉得没问题”的心理暗示，模型会下意识地为自己的代码辩护，从而漏掉诸如竞态条件、边界异常等隐蔽 Bug。
- 独立 Agent 拥有独立的上下文边界。它读取最新背景、“需求契约”、“架构方案”、“实际代码 Diff”及必要的代码上下文，不继承完整的编码对话和实现者的自我评价。它需要知道业务前因后果，但不被前面的实现推导牵着走，从而降低确认偏误的影响。
3.什么是 SubAgent？
- 角色定位：由主 Agent 动态派生、专门处理特定繁重子任务的“特种兵”（如证据调查 subAgent）。
- 为什么需要它（解耦与噪声治理）：
- 上下文污染治理：在排查复杂 Bug（如蓝牙通信失败、数据同步异常）时，往往伴随着几兆大小的运行日志或多张界面截图。如果全部喂给主 Agent，会迅速耗尽主会话的上下文窗口并引入大量噪音。
- 并行调查与降本增效：subAgent 可以在独立任务上下文中对海量日志、时序数据或接口契约进行深度挖掘，过滤掉无关信息后，只向主 Agent 提交结构化的事实摘要和关键证据。对彼此独立的调查按需并行，有助于保护主 Agent 的注意力并提升复杂任务的排查效率；实际收益仍取决于任务规模与交接成本。
四、让 Agent 真正进入工作流：从角色分工到交付闭环
明确角色之后，还需要把这些角色放回真实的研发任务中，建立一条清晰的协作链：谁负责推进、交接什么、何时进入下一阶段，以及失败后如何处理。
关键在于，每个阶段都要解决一个不同的问题，并向下一阶段交付可核对的结果。角色分工只有与输入、输出、权限和失败处理绑定起来，才能成为真正可执行的工作流。
1. 先分清两个维度：工作职责与协作方式
前文提到的角色，实际上处在两个不同的维度：
- Context Analyst、Planner、Coder、Reviewer、Tester：描述“当前要承担什么职责”。它们分别关注背景、方案、实现、审查和验证。
- 主 Agent、独立 Agent、SubAgent：描述“由谁组织任务、如何划分上下文、如何委派工作”。
因此，五种工作职责并不意味着每次都要启动五个 Agent。在这套设计中，主 Agent 默认承担 Context Analyst、Planner、Coder、Tester 及最终汇总Delivery Coordinator；独立 Reviewer Agent 在 Phase 3 使用独立任务上下文审查；证据调查 SubAgent 则在日志分析、时序还原等工作确实复杂时按需介入。
一个 SubAgent 也可以承担独立 Reviewer 的职责，前提是它使用独立的审查上下文，且没有参与本次实现或诊断结论的形成。这里的“独立”，强调的是审查视角与上下文边界；“SubAgent”强调的是任务的委派关系。两者并不是互斥的产品类型。
人类工程师则保留业务目标、方案取舍和阶段放行的决策权。主 Agent 可以组织推进，但不能代替人类确认需求，也不能替独立 Reviewer Agent宣布审查通过。
2. 各阶段如何接力？
Phase 0：Context Analyst 先确认“我们究竟要解决什么问题”
- 输入：用户描述、已有需求、相关代码、历史决策，以及能够取得的接口、设备协议或故障资料。
- 工作内容：还原功能目标，区分当前行为与目标行为，整理影响范围、必须保留的规则和关键未知。
- 交付物：背景分析和背景说明，原有的需求是什么；对于 Bug 修复，还要形成包含“触发条件、预期结果、实际表现、证据来源”的故障基线。
- 交接条件：人类工程师确认背景与问题边界后，再进入方案阶段。背景确认只表示双方理解一致，不代表故障原因已经定位。
例如，用户反馈“蓝牙重连失败”，Context Analyst 需要先弄清：需求中连接是如何建立的、为什么现在没有建立、连接成功后页面没有更新，还是切换设备后旧连接仍在回调。这几种现象看起来相似，修复方向却完全不同。
为什么需要这一阶段：模型很容易把用户描述中的现象直接当成原因。如果没有故障基线，后续即使代码写得正确，也可能修复了另一个问题。
Phase 1：Planner 把背景转成“可实现、可审查、可验证的方案”
- 输入：已确认的背景与边界、相关代码关系，以及必要的调查证据。
- 工作内容：明确修改范围与不修改范围，设计状态流、模块职责、异常处理和兼容策略，列出实现任务及验收标准。
- 交付物：技术方案与验证契约。验证契约说明每条验收标准准备如何核对，需要什么证据，以及哪些项目依赖人工或真机验证。
- 交接条件：人类工程师确认方案后，Coder 才能开始修改代码。
在 bugfix-workflow 中，主 Agent 还要先承担 Investigator 的职责，交叉核对代码与故障证据，再以 Planner 的身份设计修复。证据不足时，应明确本轮是继续取证还是实施修复，不能把一个猜测包装成已经确认的根因。
为什么需要这一阶段：方案让“模型打算怎么改”在编码前变得可见；验收标准则提前定义“怎样才算完成”，避免模型写完代码后再挑选有利于自己的完成条件。
Phase 2：Coder 在已确认的边界内完成实现
- 输入：已确认的方案、允许修改的模块或文件范围、项目规范及验收标准。
- 工作内容：读取相关代码，按任务清单实现，复用已有能力，并执行允许范围内的轻量静态检查。
- 交付物：实际代码 Diff、变更文件列表、静态检查结果，以及与原方案的偏差说明。
- 交接条件：主 Agent 汇总实现结果，人类工程师完成当前关卡的实现验证与放行后，再交给独立 Reviewer。
如果编码过程中发现方案依赖的接口不存在，或者现有生命周期无法支撑原设计，Coder 需要把事实和影响反馈给主 Agent，更新相关方案与验收标准。涉及实质性取舍时，由人类工程师确认，不能顺手扩大范围或更换目标。
为什么需要这一阶段的权限约束：模型常常会在实现一个功能时顺便重构周边代码。限制 Coder 的修改范围，可以控制 Diff 的规模，也让后续审查更容易识别真正影响行为的变更。
Phase 3：独立 Reviewer检查“目标是否实现，工程上是否可靠”
- 输入：最新背景、已确认方案、验收标准、实际代码 Diff、必要的调用上下文及项目规范。
- 工作内容：同时进行需求正确性与工程正确性审查。前者检查有没有做错目标、遗漏规则或越出范围；后者检查协程与生命周期、异步竞态、异常处理、资源释放等工程问题。
- 交付物：审查结论与问题列表。问题应包含代码位置、触发条件、具体影响及判断依据。
- 交接条件：审查通过后进入验证；未通过则由主 Agent 核实问题、组织 Coder 定点修复，再交回独立 Reviewer 复核。
Reviewer 不直接接管业务实现。这样可以保留“提出问题—修复问题—复核结果”的责任链，避免审查者一边改代码，一边为自己的修改作出通过结论。
为什么必须保留独立上下文：主 Agent 切换一句“现在我是 Reviewer”，并不会清除它之前的实现思路。独立 Reviewer 需要基于需求、方案和代码重新作出判断，而不是延续 Coder 的自我解释。
注意：如果开发或修复的问题很简单，则单独开一个Reviewer Agent是没有必要的，可直接在主Agent中审查。
Phase 4：Tester 对照验收标准核对“哪些结果已经得到证据支持”
- 输入：审查后的最新实现、验证契约、故障基线，以及对应版本的日志、截图或其他可用验证资料。
- 工作内容：逐条核对验收标准，检查原始触发场景、相邻正常路径与相关边界，区分已通过、已失败和待人工验证的项目。
- 交付物：验证报告，写明实际执行的检查、证据来源、未执行项及原因，必要时附上人工回归清单。
- 交接条件：已知失败项进入定点返修；具备充分证据的项目才能标记通过，尚未运行的项目保留为待验证。
在Android 工程约束下，AI 默认执行静态检查、逻辑核对和现有证据分析，不主动编译项目，也不新增测试用例；编译、运行与真机验证按人工验证清单或后续明确授权处理。因此，Tester 必须明确区分“静态检查通过”与“真机行为已验证”，不能用前者代替后者。
为什么审查后还需要验证：Reviewer 判断的是代码是否存在可识别的问题；Tester 核对的是验收目标是否有证据支撑。尤其在设备通信场景中，回调顺序、硬件状态和网络环境都可能让代码阅读与实际表现产生差距。
Phase 5：Delivery Coordinator汇总交付，保留可继续追踪的上下文
- 输入：最终实现、审查报告、验证报告及必要的背景或需求记录。
- 工作内容：汇总改动范围、关键决策、验证结论、未解决问题和后续事项；按任务需要更新相关文档。
- 交付物：可以追溯到文件与证据的交付说明，以及明确的待人工验证清单。
- 完成边界：如果仍有真机或硬件项目未验证，应明确标记“实现与静态验证已完成，运行行为待验证”，不能笼统宣布全部通过。
为什么需要统一收尾：多个 Agent 的局部结论只有经过主 Agent 汇总，才能回答用户真正关心的问题：改了什么、解决了什么、凭什么这样判断、还剩什么没有确认。
3. SubAgent 如何参与，又为什么不负责整条流程？
证据调查 SubAgent 通常在 Phase 0 或 Phase 1 介入；Phase 4 如果需要复杂的修复前后对照，也可以复用。它的任务应当足够具体，例如：
分析指定设备在这一轮重连中的日志，按时间顺序整理断开、重试、连接回调与页面状态更新；区分已经观察到的事实与尚未证实的原因，并给出关键日志位置。
SubAgent 返回的应是时间线、关键证据、结论适用范围与未决问题。主 Agent 再把这些事实与业务背景、代码关系交叉核对，形成诊断或方案。
这条边界非常重要：调查 Agent 提供证据，主 Agent 组织决策，独立 Reviewer 审查实现。参与过诊断的调查 Agent 不兼任同一任务的独立 Reviewer，避免它在审查时继续维护自己的前期判断。
同时，独立上下文并不天然意味着工作目录或设备也被隔离。多个 Agent 共用工程或设备时，仍需明确文件所有权和操作顺序；同一台设备的页面操作、配对或取证应由一个执行者统一负责，避免调查过程相互干扰。
4. 举例用一次蓝牙重连故障串起整条链路
假设用户反馈：切换设备后，页面偶尔显示“已连接”，但当前设备实际上没有连接成功。 以下是一个假设性的处理过程：
- Context Analyst 确认目标：切换设备后，页面只反映当前目标设备的连接状态；正常重连能力需要保留。背景与边界由人类工程师确认。
- 调查 SubAgent 整理证据：时间线显示，旧设备的成功回调晚于设备切换到达，随后页面状态被更新。但这一先后关系仍需与代码调用链核对，不能只凭日志就宣布根因成立。
- Planner 制定方案：核对后确认旧会话回调能够写入当前状态，于是规划会话标识校验、旧任务取消与状态归属约束；验收标准同时覆盖旧回调被忽略、当前连接正常成功、失败状态正确展示。
- Coder 完成实现：修改已确认的连接与状态更新路径，提交 Diff 和静态检查结果，经过实现关卡放行。
- 独立 Reviewer 提出质疑：成功回调增加了会话校验，失败回调是否也会污染新会话？页面退出后，超时任务是否仍然能够更新状态？确认的问题由 Coder 返修，再交回复核。
- Tester 核对结果：对照同一组触发条件，检查对应修复版本的证据；旧版本日志只作为故障基线。没有取得真机结果的项目，明确留在人工验证清单中。
- Delivery Coordinator汇总交付：说明修复路径、审查结论、已验证范围和剩余事项，让后续验证可以沿着同一组验收标准继续。
这一过程中，工作流逐步回答了七个问题：目标是什么、现象是什么、原因依据是什么、准备如何修改、实现是否有遗漏、结果是否有证据、还有哪些未知。 任何一步出现关键缺口，都能定位到具体责任与交付物，而不必让模型从头重新猜测。
5. 为什么 dev-workflow 与 bugfix-workflow 共用骨架，却需要不同入口？
两条流程共用阶段、审批与独立审查，可以减少重复规则；分别定义背景和方案的关注点，则能防止模型把“修复问题”顺手扩大成“重新设计功能”，或者把真正的新增需求误当成局部补丁。
6. 这套流程的必要性：把错误拦在更早、更清楚的位置
结构化工作流会增加背景整理、方案说明和独立交接的成本，但它要减少的是错误决策进入代码后，反复实现、反复排查、反复回滚的成本。
- 背景阶段拦截目标错误：避免把设计行为当成 Bug，或把用户现象误当成故障原因。
- 方案阶段拦截决策错误：在代码生成前暴露状态流、模块边界和验收条件的问题。
- 实现阶段拦截范围失控：让每一处修改都能对应已确认的任务，减少无关重构与额外风险。
- 独立审查拦截实现遗漏：引入没有参与编码推导的视角，检查需求偏差与工程缺陷。
- 证据验证拦截虚假完成：把“看起来合理”“静态检查通过”和“运行行为已验证”分开记录。
- 主 Agent 收尾拦截交接丢失：保留结论、依据和未决事项，让下一轮工作能够接续。
这些机制不能保证模型永远不犯错，但能让错误更早暴露、影响范围更容易控制、完成结论更容易核实。对于设备通信、异步状态和跨模块改动，这种可追溯性正是工作流的主要价值；对于简单任务，则可以压缩报告与调查规模，避免为了角色数量而增加无效协作。
五、上下文隔离与 Token 消耗控制策略
引入多 Agent 和 subAgent 架构时，必须警惕 Token 爆炸与交接失控的问题。合理的架构设计能够在可控的协作成本下换取更高的确定性：
- 精准交接，禁止全量复制： 主 Agent 委派 subAgent 或独立 Agent 时，传递目标、必要背景、约束条件、相关代码与 Diff、结构化契约，避免把数万行历史对话全文透传。必要背景应足以理解任务，精简上下文不能以遗漏需求边界为代价。
- 只返回事实摘要，不返回原始探索过程： 子 Agent 在解析了大量日志或进行了多轮代码检索后，只向主 Agent 返回结构化的结论与关键证据（如文件行号、关键日志原文），并注明事实、推断与未知。原始探索资料保留在子上下文或调查记录中，便于主 Agent 按需回查。
- 按需启用，避免过度设计：
- 单 Agent 即可处理的轻量任务：无需进入完整研发流程的机械性单文件修改、局部 UI 文案调整或短日志解读，可以由主 Agent 直接完成；不必为了角色齐全而额外拆分任务。
- 开启多 Agent 协同：进入本文两条结构化工作流时，Phase 3 保留独立 Reviewer；额外的调查 SubAgent 则按需启用，例如需要关联多次运行的日志、还原复杂时序，或跨多个独立领域（如 API 契约与底层通信协议）展开调查。是否委派取决于工作量与任务独立性，不按日志行数机械划分。
六、 总结
结构化工作流的核心，在于把对 AI 的信任建立在制度和约束上，而不是大模型的偶然表现上。
- 通过分阶段角色与阻断状态机，把控需求到代码的每一个决策点，用确定性对抗模型的随意性。
- 通过主 Agent 贯穿 + 独立 Agent 审查，维持任务的整体连贯，并降低模型自我确认偏误带来的遗漏。
- 通过明确的输入、交付物和返修路径，让各类 Agent 的职责形成闭环，确保“背景—方案—实现—验证”始终围绕同一个目标。
- 通过证据调查 subAgent 隔离噪声、通过验证报告披露未知，保护主上下文的干净与高效，让复杂工程的 AI 辅助研发具备可追溯、可核实的交付基础。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
In day-to-day R & D, input LLM directly “help me achieve this function” or “repair this Bug” often leads to the problem of “generation codes - > deviations from original demand/technology options/ The root causes of this problem are the lack of the necessary context constraints, the lack of clear decision-making boundaries, and the “confirmation of bias” that the model is difficult to overcome during self-examination.
This paper will share a little bit of caution in designing AI to develop workflow (dev-workflow and bugfix-workflow). This paper will focus on the construction of the decision-making chain in the process, the constraints of the status machine, the division of Agent roles, and why the main Agent, independent Agent and subAgent have to be introduced into complex projects.
I. Why does workflow need to be structured?
In complex engineering, code writing is only the end of the entire R & D chain. The direct coding of the demand background and boundaries without clarifying them is highly likely to lead to design deviations. Thus, our workflow is divided into clear phases, each of which corresponds to specific roles and responsibilities:
flowchart TD
Phase0 [Phase 0: Background analysis] -- > Phase1 [Phase 1: Structure and programme]
Phase1 -- > Phase2 [Phase 2: Code Achieved]
Phase2 -- > Phase3 [Phase 3: Independent Review]
Phase3-> Phase4 [Phase 4: Evidence Validation]
Phase4 -- > Phase5 [Phase 5: Delivery and Archive]
Stages and definition of roles
II. STATE MATERIALS: ADDITILIZATION WITH A SURE COMPETITION MODEL
LLM is highly susceptible to “context drift” in long sessions - e.g., starting to generate codes when the details of the demand are not confirmed, or jumping blindly after review failure.
To that end, we have introduced a status machine and block mechanism (Checkpoint) in workflow:
stateDiagram-v2
[*] --> ContextAnalysis
ContextAnalysis -- >BackgroundPending: Background combo completed
Background Pending -- > Planning: Background approval approved
BackgroundPending -- >ContextAnalysis: Additional Background
Planning -->ProposalPending: Program completed with acceptance criteria
ProposalPending -- > Coding: Program Approval Approved (Approval)
ProposalPending -->Planning: Revised Scheme
Coding--> ImmunizationPending: Achieved and static check completed
ImplificationPending -- > Reviving: Verifying and Release
ImplicationPending--
Reviewing -- > ReviewFixing: review failed (with list of evidence)
ReviewFixing -- > Reviving: Post Rehabilitation Review
Reviewing-- : Independent review adopted
VerificationFixing:
VerificationFixing -- > Testing: fixation after validation
Testing-- > Delivery: Checked and passed, pending manual items Disclosure
Delivery -- [*]: Summary delivery and archiving
Three hard rules for the block mechanism:
- Released for key decision-making: background, programme, achievement corresponding to Checkpoint #0, #1, #2. Background confirmation is required for planning, programme confirmation is required for coding and results are validated and released for independent review. Each release only advances the current level to the next stage legally.
- Maximum number of review and validation failures: Phase 3 and Phase 4, respectively, recorded consecutive failures that reached a mandatory suspension of 3 times, with human engineers intervening; no replacements to prevent models from entering an infinite cycle of self-repair.
- Reliable delivery driven by evidence: Before entering the delivery phase, static inspections, logs, stoppages or other corroborating evidence must be given for actual execution, and acceptance check states must be indicated article by article. Projects that still need to be compiled, run or validated must be clearly identified and should not substitute for operational conclusions by subjective descriptions or static results.
III. In-depth understanding of the Agent architecture: Master Agent, Independent Agent and SubAgent 's philosophy of synergy
In the evolution of AI workflow, the limitations of single Agent are becoming more pronounced: when the task becomes ambitious and context becomes lengthy, the models in a single context face distractions, logical confusion and serious confirmation errors. The introduction of multi-Agent synergetic structures is therefore imperative.
In practice, however, we must clearly distinguish between their responsibilities and the value of existence:
1. What's Lord Agent?
- Role positioning: “project manager” and “core brain” throughout the mission.
- Duties and missions:
- Responsible for controlling overall progress and maintaining the core context (e.g., original needs, architecture programmes, main deliverables).
- A steady flow of the driver from Phaase 0 to Phaase 5.
- Integration of the global system, the external distribution of subtask as required and the consolidation, verification and arbitration of the results submitted by sub-Agent.
- Why is it indispensable: Agent, without the master, is in a state of fragmentation of the herd; it is the only anchor that guarantees the logical consistency of the entire research and development stream.
What is independence?
Role positioning: “external experts” with an independent mandate context.
- Why do you need it?
- In the traditional single Agent mode, the code is the same as the review code. When it “thinks for itself”, because history context is filled with the psychological insinuation that “I just thought” and “I think this logic is okay”, the model will consciously defend its own code, thus missing the hidden Bugs, such as competitive conditions, border anomalies, etc.
- Independent Agen has an independent context border. It reads up-to-date background, “compact of demand”, “structure programme”, “actual code Diff” and the required code context, and does not inherit full code dialogue and self-evaluation by the implementer. It needs to be aware of the pre-operational consequences, but is not driven by the prior realization, thereby reducing the impact of the identification of bias.
What's SubAgent?
- Role positioning: “special forces” (e.g., sub-investigation of evidence) created by the main Agent dynamic, specializing in specific heavy subtask.
- Why do you need it?
- context pollution management: When searching complex bugs (e.g. failure of Bluetooth communications, data synchronisation anomalies), often accompanied by several trillions of operating logs or multiple interfaces. If all were fed to the master Agent, context window would quickly exhaust the main session and introduce a large amount of noise.
- Parallel investigations and efficiency gains: subAgent can only submit structured facts summary and key evidence to the main Agent after deep excavation of mass logs, time series data or interface compacts, filtering out irrelevant information. An independent investigation of each other, in parallel with each other, would help protect the attention of the main Agent and increase the efficiency of the processing of complex tasks; the actual benefits would still depend on the scale of the task and the cost of the transition.
IV. Enabling Agent to enter workflow: from role division to delivery loop
Once the roles are clearly defined, there is a need to put them back into real R & D tasks, creating a clear chain of collaboration: who is responsible for pushing, what to do, when to move into the next phase, and how to deal with them when they fail.
The key is to address a different issue at each stage and deliver verifiable results to the next. The division of roles can become a truly enforceable workflow only if tied to input, output, permission and failure processing.
First, two dimensions: job responsibilities and collaborative approaches
The role mentioned above is in fact at two different dimensions:
- Context Analyst, Planner, Coder, Reviewer, Tester: describe “what duties are currently to be performed”. They focus on context, programme, realization, review and validation.
- Master Agent, Independent Agent, SubAgent: Describe “Who organizes the mission, how to divide context and how to delegate”.
Therefore, the five job responsibilities do not imply the initiation of five Agents each time. In this design, the main Agent defaults to assume the responsibility of Context Analyst, Planner, Coder, Tester and eventually consolidate Deliberator; independent Reviewer Agent uses an independent task context review in Phase 3; and SubAgent for the evidence investigation intervenes when the log analysis, time series restoration, etc. are really complex.
A SubAgent may also assume the role of an independent Reviewer, provided that it uses an independent review of context and is not involved in this realization or the formulation of the diagnosis. In this context, “independence”, emphasis is placed on the review perspective at the border with context, and “SubAgent” on the assignment of tasks. The two are not mutually exclusive product types.
Human engineers retain decision-making power over operational objectives, programme trade-offs and phase release. Lord Agent can organize the push, but not as a substitute for human recognition of needs, nor can he announce the review for independent Reviewer Agent.
2. How are the phases relayed?
Case 0: Context Analyst first confirms "what are we going to solve?"
- Enter: user description, existing needs, relevant codes, historical decision-making, and access to interfaces, equipment protocols or malfunctioning information.
- Work content: Revert functional objectives, distinguish between current and targeted behaviour, codify the scope of influence, the rules that must be retained and the key uncertainties.
- Deliveries: background analysis and background description, what the original needs are; for Bug repair, a failure baseline containing “trigger conditions, expected results, actual performance, sources of evidence”.
- Conditions of handover: Human engineers confirm background and problem boundaries before proceeding to the programme stage. Background confirmation indicates only that there is a common understanding between the parties and does not mean that the cause of the failure has been positioned.
For example, the user feedback “Bluetooth failure” and Context Analyst needs to know first how the connection in demand was built, why it was not created now, why the page was not updated after the connection was successfully made, or whether the old connection was returned after switching the device. These phenomena appear to be similar, but the repairs are completely different.
Why this stage is needed: models can easily take the phenomenon described by users as a direct cause. In the absence of a failure baseline, a subsequent problem could have been repaired even if the code had been correctly drafted.
Phase 1: Planner to change the background to "achievable, reviewable, verifiable"
- Entry: The identified background relates to the boundary, the relevant code, and the necessary investigative evidence.
- Work content: clear scope and non-modification, design of state flow, modular duties, abnormal handling and compatibility strategy, listing tasks to be achieved and acceptance criteria.
- Deliveries: technical programmes and certification contracts. The certification contract describes how each acceptance criteria is to be reconciled, what evidence is required and which items rely on manual or genuine authentication.
- Handover conditions: After human engineers confirm the program, Coder can start changing the code.
In the bugfix-workflow, Major Agent also assumes the responsibility of Investigator for cross-checking the code with the evidence of failure, which is then designed and repaired as Planner. Where there is insufficient evidence, it should be made clear whether the current round continues to take evidence or to carry out repairs, and a speculation cannot be packaged as an established root cause.
Why this stage is needed: the programme makes “how the model is intended to be changed” visible before the code is coded; and acceptance criteria defines “how is done” well in advance and avoids having the model write the code before selecting the conditions for its completion.
Phase 2: Coder within identified boundaries
- Enter: the program identified, module or document range allowed to be modified, project specifications and acceptance criteria.
- Work content: Read the relevant codes, achieve them according to the list of tasks, reuse the capabilities available and carry out light static inspections to the extent permitted.
- Deliveries: Actual code Diff, list of change documents, results of static checks, and description of deviations from original programmes.
- Hand-over conditions: Master Agent consolidates the results and human engineers complete the validation and release of the current level before handing them over to an independent Reviewer.
If it is found in the encoding process that the programme relies on an interface that does not exist or that the current life cycle does not support the original design, Coder needs to provide feedback on the facts and impacts to the main Agent, updating the relevant programme and acceptance criteria. When substantive trade-offs are involved, it is confirmed by human engineers that the scope cannot be expanded or objectives replaced.
Why is permission binding at this stage needed: Models often re-engineer perimeter codes as they achieve a function. Limiting the scope of Coder 's modifications can control the size of Diff and make it easier for follow-up reviews to identify changes that really affect behaviour.
Phase 3: Independent Reviewer Checks "Whether the goal has been achieved and if the project is reliable"
- Enter: the latest background, confirmed program, acceptance criteria, actual code Diff, necessary call context and project specifications.
- Work content: a review of the correctness of requirements and the correctness of works is conducted simultaneously. The former examines whether there are faulty targets, missing rules or going beyond the scope; the latter examines engineering issues such as the process and life cycle, the heterogeneity, unusual handling, and resource release.
- Deliverables: list of conclusions and issues of the review. The question should include the location of the code, the trigger conditions, the specific effects and the basis for the judgement.
- Conditions of handover: Access to validation after review; failure to pass by the main Agent verification, organization of the Coder fixation, return to independent Reviewer for review.
Reviewer does not directly take over operations. This would allow the chain of responsibility to be retained for “questioning—repair—reviewing the results” and would avoid reviewers changing codes while adopting conclusions on their own modifications.
Why do you have to keep independent context: Lord Agent to switch to "now I'm Reviewer" and not clear the way it was achieved. Independent Reviewer needs to re-judge on the basis of needs, programmes and codes, rather than renew Coder ' s self-interpretation.
Note: If the issue of development or restoration is simple, a single Reviewer Argentina is unnecessary and can be examined directly in the main Agent.
Chase 4:Tester cross-checks "What results are supported by evidence" against acceptance criteria.
- Input: Reviewed latest realization, validation contract, failure baseline, and corresponding version of logs, screenshots or other available authentication information.
- Work content: check article by article acceptance criteria, check the original trigger scene, the normal adjacent path and the relevant boundary, distinguishing between items that have been passed, failed and items that are subject to manual verification.
- Delivery: Validation report, indicating the inspection actually performed, the source of evidence, the non-implementation item and the reasons for it, with a manual regression list if necessary.
- Conditions for handover: A known failure enters a fixed site for refurbishment; a project with sufficient evidence is marked to pass and a project that is not yet operational remains to be validated.
Under the constraints of the Android project, AI defaults to carry out static checks, logical checks and analysis of available evidence, does not initiate the compilation of projects and does not add test examples; compiles, operates and authenticates are processed by manual validation lists or subsequent express authorization. Thus, Tester must make a clear distinction between “static inspection” and “real machine conduct proved”, which cannot be replaced by the former.
The review also needed to verify that Reviewer judged whether the code was identifiable; and Tester checked whether the acceptance check target was supported by evidence. In particular, in the equipment communications scene, back-sequences, hardware status and the network environment can create gaps between code reading and actual performance.
Chase 5: Deliver Coordinator aggregate delivery, retain trackable context
- Input: Finalization, review of the report, validation of the report and necessary background or record of needs.
- Work: Summary of scope of changes, key decisions, validation of conclusions, unresolved issues and follow-up matters; update of relevant documentation as required by the mandate.
- Delivery: can be traced back to the statement of delivery of documents and evidence, as well as to a clear list to be manually validated.
- Completion of the boundary: If there are still real machines or hardware items that have not been verified, the "achievement and static certification have been completed and the conduct of the operation is yet to be verified" should be clearly marked, and it cannot be declared in general terms.
Why does it need to be done in one way or another: the partial conclusions of various Agents can only be summarized by the main Agent to answer the real concerns of users: what has been changed, what has been solved, what has been judged, and what remains is not confirmed?
3. How does SubAgent participate and why is it not responsible for the whole process?
SubAgent is usually involved in Phase 0 or Phase 1; Phase 4 can also be reused if complex repairs are required. Its mandate should be specific enough, for example:
Analyses the logs of the specified device in this cycle of reconnection, arranges the break-up, retry, connect back-to-back and page status updates in chronological order; distinguishes between observed facts and unproven causes and gives key log locations.
SubAgent returns should be timeline, key evidence, scope of application of conclusions and outstanding issues. Major Agent then cross-checks these facts with business background, code relationships to form a diagnosis or programme.
This boundary is very important: the investigation Agent provides evidence, the main Agent organizational decision-making, and the independent Reviewer review works. Agent was involved in a diagnostic survey and was not part of the same mission as an independent Reviewer to avoid it continuing to maintain its own prior judgement in the review.
At the same time, independent context does not automatically mean that working directory or equipment is also isolated. In the case of multiple Agent projects or equipment, the document ownership and order of operation still need to be clarified; the page operation, matchmaking or evidence of the same equipment should be the responsibility of a single implementer, avoiding interference in the investigation process.
4. For example, the entire chain is linked by a single Bluetooth failure
Assume user feedback: After switching the device, the page occasionally shows " connected ", but the current device is not actually connected successfully. The following is an hypothetical process:
- Context Analyst confirms the target: after switching the device, the page reflects only the current state of connection of the target device; normal reconnectivity needs to be maintained. The background and boundary are confirmed by human engineers.
- Investigation SubAgent collates evidence: The time line shows that the successful return of the old device is later than the device switch arrives and the page status is subsequently updated. This sequence, however, still needs to be checked against the code transfer chain and cannot be declared valid solely by the log.
- Planner sets the program: after checking, confirm that the old session is written into the current state, and then plans the session identification check, the old task is cancelled and the status attribution constraints are restricted; acceptance criteria also covers the neglected, current connection is successful and failure is correctly displayed.
- Coder completes: modifys the confirmed connection and status update path, submits the Diff and static check results, and is released through the realization level.
- Independent Reviewer questioned whether a successful callback added a session validation, and whether a failure would also contaminate a new session. Can the timeout job still be updated after the page exit? The identified problem was reversed by Coder, which was then referred back.
- Test the evidence against the restored version against the same set of triggers; the old version of the log serves only as the failure baseline. Projects that do not produce real results are clearly left on the manual validation list.
- Delivery Coordinator ' s Summary Delivery: Description of repair path, review findings, verified scope and remaining matters, allowing for subsequent validation to continue along the same group of acceptance criteria.
During this process, workflow gradually answered seven questions: what was the objective, what was the phenomenon, what was the basis for it, how it was intended to be modified, whether it had been achieved, whether there was evidence of the results and what was not known. Key gaps in any one step can be traced to specific responsibilities and deliverables, without the need for models to re-guess from scratch.
Why do you need different entrances when you share a skeleton with a bugfix-workflow?
The sharing phase of the two processes, approval and independent review would reduce duplication of rules; defining the context and focus of the programme separately would prevent the model from expanding “repair problems” to “redesign functions” or misusing real additional needs as partial patches.
6. The need for this set of processes: stopping mistakes earlier and clearer
Structured workflow increases the costs of backgrounding, programme descriptions and independent handovers, but it reduces the costs of repeated realization, repeated searching and rollbacks when wrong decisions enter codes.
- Background phase intercept target error: avoid treating design behaviour as Bug or the user phenomenon as a cause of failure.
- Interception of decision error at the programme stage: problems of exposure of state flow, modular boundary and acceptance check conditions before code generation.
- Uncontrollable scope of interception at the realization stage: each modification is tailored to the identified tasks and reduces unrelated re-engineering and additional risks.
- Independent review of gaps in interception: introduce a perspective that is not coded and examine needs deviations and engineering deficiencies.
- Evidentiary verification of false completion of interception: separate records of “seemingly reasonable” “static inspection” and “acts of operation verified”.
- Master Agent, the cut-off was lost: leave the conclusions, the basis and the outstanding matters open so that the next round of work could continue.
These mechanisms do not guarantee that the model will never make mistakes, but they allow for earlier exposure of errors, easier control of the scope of impact and easier verification of conclusions. This traceability is the main value of workflow for equipment communication, heterostatus and cross-module changes; for simple missions, reporting and survey size can be reduced to avoid increasing ineffective collaboration for role numbers.
V. context Segregation and Token Consumption Control Strategy
When introducing multiple Agent and subAgent structures, it is important to be alert to the problem that the Token explosion and the intersection are out of control. Reasonable architecture can be designed in exchange for greater certainty at manageable collaboration costs:
- Precise handover, prohibition of full copying: When the main Agent assigns subAgent or independent Agent, pass on the target, the necessary background, the constraints, the relevant codes and Diff, the structured contract, and avoid passing through tens of thousands of lines of historical conversations. The necessary background should be sufficient to understand the mandate, and streamlining context should not be at the expense of missing demand boundaries.
- Return only to the fact that summary does not return to the original exploration process: After deciphering a large number of logs or conducting multiple-wheel code searches, only return to the main Agent to structured conclusions and key evidence (e.g. document line numbers, key logs in the original language) and indicate facts, assumptions and unknown. The original exploration material is kept in a sub-context or investigation record and is easily retraceable by the main user, Agent.
- Enable on demand to avoid over-design:
- Light tasks that can be handled by single Agent: mechanical single file modifications, local UI script adjustments or short log reading that do not require access to the full R & D process can be performed directly by main Agent; no additional split tasks need to be performed for full role.
- Start multiple Agent synergetics: when entering two articles of this paper structured workflow, Chase 3 retains an independent Reviewer; additional investigations SubAgent is activated as needed, for example by linking multiple running logs, restoring complex time lines, or conducting investigations across multiple separate domains (e.g. API contracts and bottom communication agreements). Assignment is dependent on workload and mandate independence and is not mechanically divided according to log lines.
VI. Summary
The core of the structured workflow is to base trust in AI on institutions and constraints, not on the occasional performance of LLM.
- Use of a staged role and blocker to move demand to each point of the code ' s decision-making, with certainty against the arbitrariness of the model.
- Maintaining the overall coherence of the mission through the main Agent cross- + independent Agent review and reducing the gaps caused by model self-identification errors.
- To ensure that the “background-program-achievement-certification” is always centred on the same objective by creating a closed circle of all types of Agent's responsibilities through clear input, delivery and retrieval pathways.
- To protect the cleanness and efficiency of the main context by investigating the evidence subAgent to isolate the noise, by disclosing the unknown through the validation report, and to provide a retroactive and verifiable basis for delivery of AI support for complex projects.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.