先给一个默认答案：生产架构应该长什么样
如果一定要先给一个默认方案，我会把长时间 Agent 拆成七层：Task API、Planner、Orchestrator、Worker Runtime、State and Memory、Verification and Recovery、Observability and Governance。这样分不是为了显得完整，而是为了把问题放回它真正该解决的层里。
最关键的部分，其实不是 Planner，而是 Orchestrator、State 和 Verification。Planner 负责理解目标和拆分任务，但真正决定系统能不能跑起来、坏了能不能续上、成本会不会失控的，是编排层、状态层和验证层。很多团队第一次做长任务系统时，会本能地把注意力全放在“怎么让 Agent 更聪明”；到了第二版才发现，真正拖住系统的往往不是智能不够，而是流程、状态和恢复太薄。
所以这套蓝图的出发点很简单：别指望一个 Agent 从头到尾自己把长链路处理得完美，而要让系统把任务拆成很多短、可控、可回滚的步骤。
User / Upstream System
│
▼
Task API / Job UI
│
▼
Planner (strong model)
- goal understanding
- decomposition
- acceptance definition
│
▼
Orchestrator / State Machine
- scheduling
- retries
- checkpoints
- budgets
│
┌──────┴──────────────┐
▼ ▼
Worker Runtime Verification / Review
- tool calls - tests
- code changes - schema checks
- browser ops - reviewer LLM
- API execution - human gates
│
▼
Artifacts / State / Decision LogsPlanner、Orchestrator、Worker 各自负责什么
Planner 只做高杠杆决策：理解目标、生成任务树、标注依赖、给每个子任务定义验收标准和风险等级。它不应该沉到每一个工具细节里，更不应该自己去执行所有原子操作。
Orchestrator 是系统真正的主心骨。它负责把任务树变成可执行状态机，负责调度 Worker、落 checkpoint、执行重试、控制并发、统计预算、触发审查和决定是否升级给人类。你可以把它理解成一个 workflow engine，而不是一个会思考的 Agent。
Worker 则应该尽可能保持轻：只拿当前子任务、必要约束和少量上下文，执行有限范围内的工具调用，然后返回结构化结果。Worker 不负责全局战略，也不应该看到整个任务历史。
- Planner 负责方向和拆解。
- Orchestrator 负责流程、状态和预算。
- Worker 负责局部执行和结构化回报。
{
"goal": "ship feature safely",
"assumptions": [
"repository builds successfully",
"staging credentials exist"
],
"tasks": [
{
"task_id": "T1",
"title": "inspect impacted modules",
"depends_on": [],
"tools": ["filesystem", "git", "tests"],
"acceptance": [
"changed files identified",
"risk note recorded"
],
"risk_level": "low",
"requires_human_approval": false
}
]
}为什么任务必须拆成短步骤
稳定的长任务，并不是来自一个 Agent 连续思考三小时，而是来自很多短步骤被稳定地串起来。经验上，最稳的执行单元往往是 2 到 15 分钟的人类等价工作量。超过这个尺度，问题会迅速恶化：上下文噪音变多、定位成本变高、失败半径变大。
每个步骤都应该具备五个属性：明确输入、有限工具、结构化输出、可验证的完成条件，以及独立重试能力。如果某一步失败会导致整条链路只能从头重跑，那就说明拆分粒度还不够细。
从系统设计角度看，任务拆细不是为了“形式上更模块化”，而是为了让失败变得便宜，让恢复有抓手，让观察和统计变得可能。
- 单步的目标要小到能被 reviewer 或规则验证。
- 单步失败要小到不需要整条链路重来。
- 单步输出要结构化到可以进入下一层状态机。
状态层应该保存哪些东西
长时间 Agent 默认是一种有状态系统，所以最关键的不是 prompt 模板，而是状态模型。事务状态适合放数据库，例如任务、运行实例、步骤、尝试次数、审批、预算、验证结果。大对象产物适合放文件系统或对象存储，例如 patch、日志、截图、浏览器录屏和中间 JSON。
除此之外，还有一类经常被低估的信息：决策理由。很多团队会做向量记忆，却不认真做 decision log，结果系统一旦中断，恢复者只能看到“做了什么”，看不到“为什么这样做”。对长任务来说，这会大幅增加重复决策和错误回滚的风险。
所以我的建议是：先做结构化 decision log，再考虑语义检索。没有可靠日志的向量记忆，价值远低于很多团队想象。
tasks
task_runs
steps
step_attempts
checkpoints
artifacts
decisions
approvals
verifications
cost_events{
"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。第一层是系统级不变量，例如安全边界、工具权限和输出格式；第二层是任务级上下文，例如目标、成功定义、风险偏好和阶段状态；第三层是子任务级上下文，例如当前步骤目标、依赖输入和验收条件；第四层才是即时工作记忆，例如最近几轮观察、命令输出摘要和待处理异常。
真正需要高频压缩的，通常只有第四层。前面三层更像制度和地图，第四层才是现场。如果把这四层混在一起，模型很容易把临时现象当成长期约束，把已经失效的观察当成仍然成立的规则。很多“上下文太长”“模型开始绕圈”“任务越跑越飘”的问题，本质上都不是窗口不够，而是现场信息没有被及时收束。
压缩产物也最好别停在一大段自然语言总结上。更稳的做法，是输出结构化摘要，让下一步系统能明确知道已经做了什么、发现了什么、哪些风险还挂着、接下来最合理的动作是什么。
{
"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，而不是只靠历史对话。
Level 1: retry in place
- transient network failure
- timeout
- short rate limit
Level 2: retry with compressed context
- context too long
- output drift
- repeated loops
Level 3: rollback to checkpoint
- state pollution
- artifact inconsistency
- bad decision propagation
Level 4: escalate to human
- high risk action
- retry threshold exceeded
- budget near exhaustion验证防线要做成三层，而不是一句“自测一下”
长任务最怕的不是失败，而是假完成。因此验证必须被设计成分层防线。第一层是 deterministic checks，例如 JSON schema、类型检查、lint、单元测试、SQL dry-run、权限校验、文件存在性校验。这一层最便宜，也最值得优先建设。
第二层是 reviewer LLM，用来做语义审查、目标对齐检查和关键逻辑复核。它的职责不是替代确定性校验，而是补上“规则很难完全表达”的那部分灰度判断。第三层则是 human approval，只拦高风险动作，如生产写操作、数据库迁移、删除数据、外发正式内容和权限变更。
一套成熟系统的核心不是“让模型自己评估自己”，而是让不同层级的验证在不同成本点上各司其职。
- deterministic checks 先于 LLM review。
- LLM reviewer 应该与执行器解耦。
- 高风险动作必须显式过人。
成本工程不能后补
很多长时间 Agent 不是技术上先死，而是成本先炸。长任务的 token 消耗不是线性增长，而是常常随上下文膨胀、评估循环和重试次数一起上升。没有预算系统的 Agent，非常容易在错误路径上花掉远超预期的费用。
所以预算至少应有三层：任务预算、阶段预算和模型预算。任务预算定义单任务最多跑多久、花多少钱、调用多少次模型；阶段预算限制 planning、execution 和 review 各自的消耗；模型预算限制强模型总调用次数，防止每一步都无脑走最贵路径。
此外，缓存、模型路由和工具优先于语言描述，都是非常重要的成本优化手段。能直接查数据库就别让模型猜，能直接跑测试就别让模型推测“应该没问题”。
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。
- “完成”必须定义成验证通过，而不是模型自述。
更新附注
- 版本：v1.1
更新日期：2026-03-31 更新原因：重写开头、上下文分层与工具栈实施顺序，压缩口号化表达，把蓝图从“条目汇总”改得更像一篇可执行的工程说明。
还没有评论，你可以写下第一条。