工作方法

用 AI 交付项目时，我怎么组织 Agent、怎么把关质量。

三种组织方式

Single-Agent Loop

适合边界清晰、可以一次说明清楚的任务。整个任务交给一个强模型，由它自主完成规划、实现、测试、修复，循环到达到验收标准为止。

见于上一版个人网站

Multi-Node Graph

适合规模大、可以拆分的任务。按依赖关系拆成 DAG，每个节点有独立的 Task Spec；没有依赖、改动不冲突的节点用 worktree 受控并行。

Coordinator + Sub-agents

适合量大、需要统一判断的任务。强模型作为 Coordinator，负责规划、拆分、集成和最终判断；边界明确的执行交给低成本的子 Agent；关键节点由没参与实现的模型独立复核。

Rule → Low-code → Code → LLM

能用规则解决的，不交给模型。

能用规则的不用模型，能用低代码的不急着写代码；需要长期运行或精细控制时才写成代码。LLM 只放在需要判断和生成的环节。

Context Isolation

每个角色只看完成本职所需的信息。

每个角色只接收完成本职所需的输入，比如 Writer 只读 Researcher 的笔记，Reviewer 只读稿件和出处。再用 Structured Output 和 Schema 约束输出，减少漂移。

Task Spec & Handoff

写清规格，状态进 Git，随时可以接着做。

每个节点写清起始版本、依赖、可改和禁改范围、交付物和验收标准。进度、改动、测试结果和下一步都写进 Git，换模型、换会话都能接着做。

Quality Gate

返工有上限，发布由规则决定。

着手之前，先判断最可能在哪些环节失效，先测这些环节。Reviewer 不通过就返工，返工有上限，超过上限就 HOLD、转人工；是否发布由确定性规则决定，不交给模型。故障分级处理：单条出错 Fail-soft 跳过，配置、密钥或数据源故障 Fail-fast 停机告警。

Evidence-based Acceptance

以运行结果为准，不以“完成”汇报为准。

以代码改动、运行结果、数据库和页面为准，不以 Agent 自报“完成”为准。每个结论的来源、获取时间和适用范围都留有记录，事后可以回溯核查；关键结论由多个模型独立复核、分开记录。

Human-in-the-loop

高风险操作，必须停下来确认。

可撤回的常规操作让 Agent 自主推进；涉及删除、资金、密钥，或者业务含义不明确时，暂停确认。推进是能力，及时停止同样是：方向偏离的稿件、没过审核的结果、证据不足的结论，退回修改、暂缓发布或终止。