11 总结、FAQ与资源

11 总结、FAQ与资源#

核心要点总结#

一个核心主张#

框架会更迭，Protocol对象更稳定。 学Agent不要只学框架API，要学Thread/Run/Step/Event/Artifact/Checkpoint这六大Protocol对象和八大维度能力。

六大Protocol对象#

对象	一句话解释
Thread/Session	这是谁的哪段任务？（长期上下文边界）
Run/Task	这次具体跑了什么？（一次执行边界）
Step	哪一步调用了模型/工具/子Agent？（最小可观测单元）
Event	现在发生了什么？（实时进展）
Artifact	结果在哪里？（正式产物）
Checkpoint	失败后从哪继续？（可恢复快照）

八大维度速查#

维度	一句话总结	生产级关键
执行模型	Loop承载方式（图/代码/托管）+ 编排协议（ReAct/Plan/Handoff）会长期分层共存	不要押注单一模式，让能力独立于执行模型
状态管理	五层状态（Conversation/Run/Checkpoint/Artifact/Memory）必须清晰分离	Checkpoint持久化是玩具和生产的分水岭
中断恢复	HITL=状态快照+中断载荷+恢复指令+权限上下文	没有Checkpoint就没有真正的中断恢复
错误恢复	Error-as-Data优先，Checkpoint回滚是长任务必需	LLM能处理的错误不要打断执行流
工具协议	MCP正在让工具层标准化，工具与Runtime解耦	控制面（权限/Guardrail/审批/预算）是安全边界
流式输出	生产级流是任务事件流，不是token打字机	跨网络必须用可恢复SSE（Last-Event-ID）
多Agent协作	五种模式各有场景，最碎片化最不该过早押注	先做好单Agent，再按需引入协作
可观测性与评测	Trace让问题可见，评测让质量可衡量，闭环让改进可落地	没有观测的Agent是黑盒，没有评测的改进是瞎猜

九条设计原则#

对象先于API
Run是执行边界
Checkpoint是恢复契约
Event是一等公民
错误优先作为数据
控制面与数据面分离
工具协议与Runtime解耦
并发语义必须显式定义
可观测性从Day 1开始

常见问题解答（FAQ）#

Q1：初学Agent开发应该选哪个框架？#

A：如果你是初学者想快速理解概念，用OpenAI Agents SDK或Claude SDK上手快。但如果你要做生产级系统，强烈推荐LangGraph，原因是：

它是目前唯一一个在八大维度上都有完整实现的框架
Checkpoint持久化、中断恢复、可观测性都是生产级的
开源、可控、不绑定云平台
Deep Agents基于LangGraph，证明了Harness层可以在其上构建

学LangGraph的价值不只是会用一个框架，而是能理解生产级Runtime的完整能力模型。

Q2：LangGraph和OpenAI Assistants API的主要区别是什么？#

A：核心区别是控制权归属：

维度	LangGraph	OpenAI Assistants
状态管理	自建Checkpointer，完全可控	服务端托管，不可见
执行模型	图式DAG，支持复杂分支并行	服务端循环，黑盒
中断恢复	任意节点、任意载荷、完整快照	仅工具审批requires_action
可观测性	LangSmith完整Trace	Run Steps有限可见
错误回滚	Checkpoint回滚	不支持
部署方式	自托管/LangGraph Platform	OpenAI托管
成本模型	自己控制	按OpenAI定价
适合场景	复杂工作流、企业核心系统	快速原型、客服Bot

简单说：Assistants API是"给你一个托管Agent"，LangGraph是"给你一套建Agent Runtime的零件"。

Q3：为什么Error-as-Data比传统异常处理更适合Agent？#

A：三个核心理由：

LLM有推理能力：人看到错误信息会判断重试还是换方法，LLM也能。429限频等一下，401检查API key，参数错误修正参数——这些不需要开发者写try/catch。
Agent循环的本质是决策循环：错误是决策过程中的正常输入，不是异常事件。工具返回"文件不存在"，Agent应该决定是创建文件还是问用户，而不是直接崩溃。
系统级错误才需要异常：内存溢出、网络断开、权限完全不足这类LLM无法处理的故障，才应该作为Exception向上抛，触发人工介入。

Q4：MCP能替代完整的Agent Runtime吗？#

A：不能。MCP解决的是"Agent如何发现和调用工具/资源/Prompt"的问题，它是工具接入层。完整的Agent Runtime还需要：

执行循环（Loop）
状态持久化（Checkpoint）
中断恢复（Interrupt/Resume）
任务生命周期管理（Thread/Run/Step）
流式事件（Event Stream）
可观测性（Trace）
控制面（Permission/Guardrail/Budget）

MCP可以很好地作为Runtime的工具层，但Runtime本身还需要其他能力。把MCP当成"Agent标准"是过度解读。

Q5：什么时候才需要多Agent系统？#

A：在你确定单Agent无法解决问题之前，不要用多Agent。以下是真正需要多Agent的信号：

任务自然需要多个视角/角色（如产品经理+工程师+评审员）
子任务需要完全不同的工具集和上下文窗口
需要并行执行独立子任务（fan-out/fan-in）
不同团队/系统各自维护自己的Agent，需要跨组织协作
单Agent的上下文窗口无法容纳所有必要信息

如果只是想"让架构看起来高级"，多Agent只会增加复杂度。记住：一个配置良好的Plan-and-Execute单Agent，效果通常好于多个松散耦合的Agent。

Q6：生产级Agent必须具备哪些能力？#

A：按优先级排序：

P0（没有就不能上生产）：

状态持久化（进程崩溃能恢复）
基础可观测性（至少能看到Run的Step和Tool Call）
错误处理（工具失败不会直接崩溃）
基础控制面（至少有超时和取消）

P1（核心业务系统必需）： 5. 中断恢复（HITL审批） 6. Checkpoint回滚（长任务失败不丢进度） 7. 结构化Trace（能调试"为什么走了这条路"） 8. 并发控制（同一Thread的多Run策略） 9. 权限控制（工具级权限）

P2（规模化需要）： 10. 可恢复SSE流式 11. 评测系统和Badcase库 12. 多Agent协作 13. 成本预算控制 14. Schema版本迁移

大多数Demo/PoC只做到P0级别。

Q7：什么是Agent Harness？它和Runtime是什么关系？#

A：用一个类比：

Runtime = 操作系统内核（管理进程、内存、IO、调度）
Harness = Linux发行版（把内核+常用软件+默认配置打包成开箱即用体验）
Tool/MCP = 应用程序（具体功能）

Deep Agents就是典型Harness：它基于LangGraph Runtime，预先打包了Todo list、Subagent、Virtual Filesystem、Permission model、Context management等"默认软件"，让你不用从零组装就能得到一个接近Claude Code体验的长任务Agent。

Harness的价值是易用性，代价是约束——封装越强，替你做的决策越多，定制自由度越低。

Q8：可恢复流为什么重要？Library里的async generator不够吗？#

A：async generator只在同进程内工作。一旦：

用户刷新页面，连接断开
手机锁屏，SSE连接关闭
网络抖动，几秒不可用
多个前端组件订阅同一个Run

async generator就丢事件了。生产级流式必须支持：

事件持久化（不只是内存）
Last-Event-ID协议（客户端告诉服务端"我收到哪了"）
Catch-up回放（发送断连期间错过的事件）
多订阅者（多个消费者独立追踪进度）

这就是LangGraph Platform用Redis Stream、A2A/AG-UI都基于SSE的原因。

Q9：Checkpoint和普通的对话历史保存有什么区别？#

A：对话历史只保存messages，Checkpoint保存恢复执行所需的全部状态：

所有状态变量（不只是messages）
当前执行到哪个节点
pending_writes（节点已完成但尚未写入状态的副作用）
配置信息（configurable）
父Checkpoint引用（形成版本链）

简单说：对话历史能让你"看到之前说了什么"，Checkpoint能让你"从刚才暂停的地方继续执行"。后者才是真正的恢复。

Q10：作为开发者，现在应该重点学习什么？#

A：按投资回报率排序：

六大Protocol对象和八大维度（本文内容）——这是跨框架通用的认知框架，ROI最高
一个主流Runtime的深度使用（推荐LangGraph）——理解Runtime能力模型的具体实现
MCP工具开发——工具层先标准化，写一次到处能用
Prompt Engineering和Context Engineering——这是让Agent效果好的基本功，和框架无关
OpenTelemetry和可观测性基础——未来跨框架观测的标准
特定框架API细节——边用边查，不需要死记
多Agent架构模式——等你真的需要时再深入
A2A/AG-UI等互操作协议——等标准胜出者明确

最重要的是：建立判断框架——看到新框架/新产品时，能用八大维度快速分析它解决了什么问题、取舍是什么、在哪些维度上有创新，而不是被营销话术带着走。

附录A：术语对照表#

通用概念中英文对照#

中文	英文	说明
执行上下文	Execution Context	一次执行可见的所有状态和资源
执行单元	Execution Unit	一次不可分割的计算步骤
状态快照	State Snapshot	某一时刻的完整可恢复状态
状态持久化器	State Persister	负责保存和加载状态的组件
工具定义	Tool Definition	工具的名称、参数、返回值描述
工具调用结果	Tool Result	工具执行后返回给Agent的数据
中断点	Interrupt Point	执行暂停等待外部输入的位置
恢复指令	Resume Command	让Agent从断点继续的指令
流式事件	Stream Event	执行过程中的增量进展通知
子Agent	Sub-Agent	被主Agent委派执行子任务的Agent
执行追踪	Execution Trace	一次执行的完整因果链记录
错误结果	Error Result	工具或步骤失败的结构化表示
控制面	Control Plane	权限、Guardrail、预算、取消等管控能力
数据面	Data Plane	状态、事件、产物、Trace等数据流动
Harness	Agent Harness	把Runtime能力打包成默认可用体验的应用层

五大框架术语映射表#

通用概念	LangGraph	OpenAI Assistants	Agents SDK	AutoGen	Claude SDK
执行上下文	Thread + Run	Thread + Run	Runner	Runtime + Team	Session
执行单元	Node	Run Step	Agent turn	Message handler	Agent turn
状态快照	Checkpoint	Thread state	N/A	`save_state()`	N/A
状态持久化器	Checkpointer	服务端托管	N/A	手动	N/A
工具定义	`@tool` / `BaseTool`	Function	`@function_tool`	`FunctionTool`	`Tool`
工具调用结果	`ToolMessage`	Function output	Tool output	`FunctionExecutionResult`	`ToolResult`
中断点	`interrupt()`	`requires_action`	Guardrail	`HandoffTermination`	`interrupt()`
恢复指令	`Command(resume=)`	`submit_tool_outputs()`	手动代码	`run_stream(task=)`	新`query()`
流式事件	StreamPart	SSE Event	`StreamEvent`	Message	Event
子Agent	Subgraph	N/A	Handoff	Nested Team / Task tool	N/A
执行追踪	LangSmith Trace	Run Steps	SDK Traces	Console log	N/A
错误结果	error-as-data / raise	`last_error`	Exception	错误消息	Hook通知