先给一个默认答案：生产架构应该长什么样

如果要我给一个默认方案，我会把长时间 Agent 拆成七层：Task API、Planner、Orchestrator、Worker Runtime、State and Memory、Verification and Recovery、Observability and Governance。这个分层不是为了好看，而是为了让不同问题回到不同层解决。

其中最重要的不是 Planner，而是 Orchestrator 加 State 加 Verification。Planner 决定高层目标和拆解方向，但真正负责让任务能跑起来、失败能恢复、预算能受控的，是编排层、状态层和验证层。

这套分层的核心思想是：不要指望单个 Agent 自己把整条长链路处理得完美，而要让系统把任务拆成很多短、可控、可回滚的步骤。

Planner、Orchestrator、Worker 各自负责什么

Planner 只做高杠杆决策：理解目标、生成任务树、标注依赖、给每个子任务定义验收标准和风险等级。它不应该沉到每一个工具细节里，更不应该自己去执行所有原子操作。

Orchestrator 是系统真正的主心骨。它负责把任务树变成可执行状态机，负责调度 Worker、落 checkpoint、执行重试、控制并发、统计预算、触发审查和决定是否升级给人类。你可以把它理解成一个 workflow engine，而不是一个会思考的 Agent。

Worker 则应该尽可能保持轻：只拿当前子任务、必要约束和少量上下文，执行有限范围内的工具调用，然后返回结构化结果。Worker 不负责全局战略，也不应该看到整个任务历史。

  • Planner 负责方向和拆解。
  • Orchestrator 负责流程、状态和预算。
  • Worker 负责局部执行和结构化回报。

为什么任务必须拆成短步骤

稳定的长任务，并不是来自一个 Agent 连续思考三小时，而是来自很多短步骤被稳定地串起来。经验上，最稳的执行单元往往是 2 到 15 分钟的人类等价工作量。超过这个尺度，问题会迅速恶化：上下文噪音变多、定位成本变高、失败半径变大。

每个步骤都应该具备五个属性：明确输入、有限工具、结构化输出、可验证的完成条件，以及独立重试能力。如果某一步失败会导致整条链路只能从头重跑，那就说明拆分粒度还不够细。

从系统设计角度看，任务拆细不是为了“形式上更模块化”，而是为了让失败变得便宜，让恢复有抓手，让观察和统计变得可能。

  • 单步的目标要小到能被 reviewer 或规则验证。
  • 单步失败要小到不需要整条链路重来。
  • 单步输出要结构化到可以进入下一层状态机。

状态层应该保存哪些东西

长时间 Agent 默认是一种有状态系统，所以最关键的不是 prompt 模板，而是状态模型。事务状态适合放数据库，例如任务、运行实例、步骤、尝试次数、审批、预算、验证结果。大对象产物适合放文件系统或对象存储，例如 patch、日志、截图、浏览器录屏和中间 JSON。

除此之外，还有一类经常被低估的信息：决策理由。很多团队会做向量记忆，却不认真做 decision log，结果系统一旦中断，恢复者只能看到“做了什么”，看不到“为什么这样做”。对长任务来说，这会大幅增加重复决策和错误回滚的风险。

所以我的建议是：先做结构化 decision log，再考虑语义检索。没有可靠日志的向量记忆，价值远低于很多团队想象。

Text 建议的核心表 
tasks
task_runs
steps
step_attempts
checkpoints
artifacts
decisions
approvals
verifications
cost_events
JSON checkpoint 最小字段 
{
  "task_id": "job_123",
  "step_id": "T4",
  "status": "running",
  "inputs_ref": ["artifacts/plan.json"],
  "artifacts_ref": ["artifacts/test_report.json"],
  "decision_log_ref": ["decisions/2026-03-13_001.json"],
  "remaining_budget": {
    "usd": 12.40,
    "input_tokens": 180000,
    "output_tokens": 22000
  },
  "resume_instruction": "Resume from integration test triage; do not rerun completed unit tests."
}

上下文工程应该怎样分层

我更推荐把上下文固定成四层，而不是每次临时拼 prompt。第一层是系统级不变量，例如安全边界、工具权限和输出格式。第二层是任务级上下文，例如目标、成功定义、风险偏好和阶段状态。第三层是子任务级上下文，例如当前步骤目标、依赖输入和验收条件。第四层是即时工作记忆，例如最近几轮观察、命令输出摘要和待处理异常。

真正需要频繁压缩的是第四层，而不是前面三层。这样做的好处是，系统知道哪些信息是长期稳定约束，哪些信息只是阶段性工作记忆。否则模型很容易把临时状态和全局约束混在一起。

压缩的产物也不应只是自然语言段落，更适合做成结构化摘要，这样才能被下一步 reliably 消费。

JSON 压缩摘要示例 
{
  "what_was_done": [
    "ran unit tests",
    "updated parser config"
  ],
  "key_findings": [
    "failing suite is isolated to billing module"
  ],
  "open_risks": [
    "database migration not yet validated"
  ],
  "next_best_action": "run migration on staging with dry-run flag"
}

检查点和恢复应该怎么设计

长时间 Agent 默认会失败，所以恢复策略必须分层，而不是只有一种笼统的“重试”。我通常会把恢复分成四层：原地重试、压缩后重试、回滚到上一个 checkpoint、升级给人类。不同失败类型应该落到不同层，而不是一律多跑几遍。

原地重试适用于网络波动、临时限流和瞬时超时；压缩后重试适用于上下文过长和输出漂移；回滚适用于当前状态已经被污染；升级给人类适用于高风险动作前卡住、连续失败超阈值或预算快耗尽。

在生产环境里，最危险的不是偶发失败，而是无限重试。没有熔断和升级策略的 Agent，很容易在错误路径上持续烧钱。

  • 进入高风险操作前一定打 checkpoint。
  • 重试必须有退避、上限和升级条件。
  • 恢复说明应当显式写入 checkpoint，而不是只靠历史对话。

验证防线要做成三层，而不是一句“自测一下”

长任务最怕的不是失败，而是假完成。因此验证必须被设计成分层防线。第一层是 deterministic checks，例如 JSON schema、类型检查、lint、单元测试、SQL dry-run、权限校验、文件存在性校验。这一层最便宜，也最值得优先建设。

第二层是 reviewer LLM，用来做语义审查、目标对齐检查和关键逻辑复核。它的职责不是替代确定性校验，而是补上“规则很难完全表达”的那部分灰度判断。第三层则是 human approval，只拦高风险动作，如生产写操作、数据库迁移、删除数据、外发正式内容和权限变更。

一套成熟系统的核心不是“让模型自己评估自己”，而是让不同层级的验证在不同成本点上各司其职。

  • deterministic checks 先于 LLM review。
  • LLM reviewer 应该与执行器解耦。
  • 高风险动作必须显式过人。

成本工程不能后补

很多长时间 Agent 不是技术上先死，而是成本先炸。长任务的 token 消耗不是线性增长，而是常常随上下文膨胀、评估循环和重试次数一起上升。没有预算系统的 Agent，非常容易在错误路径上花掉远超预期的费用。

所以预算至少应有三层：任务预算、阶段预算和模型预算。任务预算定义单任务最多跑多久、花多少钱、调用多少次模型；阶段预算限制 planning、execution 和 review 各自的消耗；模型预算限制强模型总调用次数，防止每一步都无脑走最贵路径。

此外，缓存、模型路由和工具优先于语言描述，都是非常重要的成本优化手段。能直接查数据库就别让模型猜，能直接跑测试就别让模型推测“应该没问题”。

YAML 预算控制示例 
task_budget:
  max_usd: 25
  max_runtime_minutes: 90
  max_model_calls: 80

stage_budget:
  planning: 3 usd
  execution: 16 usd
  review: 6 usd

model_budget:
  strong_model_calls: 8
  cheap_model_calls: 72

推荐工具栈与实施顺序

如果是 Python 团队，LangGraph 适合快速搭状态图、持久化和人机协同；如果任务特别长、恢复和回放要求特别高，Temporal 更稳；如果你在微软生态内，Agent Framework 的 checkpoint 能力和 workflow 支持很值得直接利用。

状态层优先考虑 Postgres、Redis 和对象存储。工具执行层优先考虑 Playwright、隔离执行环境和 Git worktree。可观测性优先考虑 OpenTelemetry，以及专门的 LLM tracing 工具。

实施顺序上，不要一开始就多 Agent。先把单 Agent 基座跑稳：状态、日志、checkpoint、验证、人工接管。然后再引入 Planner-Worker、审查层和成本优化。太早进入多 Agent，只会让系统在还没稳定前先变复杂。

  • 第 0 期：单 Agent 基座。
  • 第 1 期：Planner-Worker 与子任务重试。
  • 第 2 期：验证加厚与人工审批。
  • 第 3 期：成本优化、缓存和模型路由。

最后给一套可以直接执行的规则

如果你今天就要带团队开工，我会更建议从规则开始，而不是从模型开始。规则的作用，是让系统在没有完美智能之前，先拥有合理的边界和可恢复性。

  • 每个任务都写清 goal / constraints / acceptance / budget / rollback。
  • 每个子任务都必须可单独重试。
  • 每个子任务都必须有可验证的完成证据。
  • 所有高风险动作都必须有人类审批。
  • 所有关键动作前后都打 checkpoint。
  • 所有原始工具输出都落盘，模型只看摘要和引用。
  • 默认先做单 Agent，不默认多 Agent。
  • “完成”必须定义成验证通过，而不是模型自述。