钩子即税：六框架生命周期横评

把一个 Agent 从 demo 推到生产，第一道分水岭不是模型，而是生命周期钩子（Lifecycle Hooks）——日志、指标、护栏、审计、成本归因、交接追踪，全靠它接入。2026 年六大主流框架（OpenAI Agents SDK、LangGraph、CrewAI、AutoGen v0.4、PydanticAI、Google ADK）暴露的钩子面差异巨大：CrewAI 只有 2/7 覆盖率且把 LLM 调用与工具调用揉成一团；OpenAI 漏了 on_llm_end；Google ADK 最规整但钩子能短路改写、是把双刃剑；LangGraph 事件最全且默认隔离异常。横评的核心结论：钩子不是"可选装饰"，覆盖率缺口会直接变成顺序阻塞税、异常逃逸税、归因盲区税三笔真金白银的损耗。

一、七事件基准：为什么先把生命周期拆成七个点

要做可比的横评，必须先定义一套跨框架统一的"标准事件面"。一个典型 agentic 运行可拆为七个里程碑：agent_start、agent_end、llm_start、llm_end、tool_start、tool_end、handoff（多智能体交接）。这七个点对应生产侧五类刚需：可观测性需要前后成对、成本归因需要 llm_end 拿到真实延迟、护栏需要 tool_start 前拦截、审计需要全链路、多智能体治理需要 handoff。

判定"原生覆盖率"的硬规则是：框架自带、无需手写胶水代码的钩子才算数。凡是要你在图节点里手动塞日志、或在 run 完成后回扫历史去反推的，都记为缺口。这套基准揭示了一个反直觉事实——星标数与钩子完整度几乎无关，覆盖最全的反而是后发的 ADK 与 PydanticAI，而"最流行"的 CrewAI 在生命周期面近乎裸奔。

二、六框架钩子面对比总表

表中数据基于各框架官方文档与 2026 年基准评测整理，"覆盖率"指开箱即用的原生点位，不含手写补丁。

三、OpenAI Agents SDK：双轨钩子的优雅与缺口

框架	原生钩子点位	七事件覆盖率	异步原生	异常隔离	可短路/改写	最致命缺口
Google ADK	`before/after × {agent,model,tool}` 共 6 回调	6/7	✓	✗	✓（最强）	handoff 无原生钩子
LangGraph	`BaseCallbackHandler` 8 点 + state 钩子	6/7	✓	✓（默认吞异常）	✗（纯观察）	handoff 需自定义 node
OpenAI Agents SDK	`RunHooks`×6 + `AgentHooks`×5	6/7	✓	✗	✗	缺 `on_llm_end`
PydanticAI	event stream（PartStart/ToolCall/ToolResult）	6/7	✓	✓（独立迭代）	✗	无 handoff 概念
AutoGen v0.4	`agent_run_hooks` + tool 钩子	4/7	✓	△（部分）	△	缺 LLM 前后细粒度
CrewAI	`step_callback` + `task_callback`	2/7	✗（同步）	✗	✗	LLM 与工具无法分拆

OpenAI Agents SDK 用双轨制解决了"全局关注"与"单 agent 关注"的分离：RunHooks 绑定在整次 Runner.run 上（on_start/on_end/on_handoff/on_tool_start/on_tool_end/on_llm_start），AgentHooks 绑定在具体 Agent 上。最巧妙的是 on_handoff——它在目标 agent 上触发，源 agent 作为参数传入，交接的因果链天然可追溯。

from agents import Agent, Runner, AgentHooks

class AuditHooks(AgentHooks):
    async def on_tool_start(self, ctx, agent, tool):
        metrics.counter("tool.start").inc(tool.name)
    async def on_tool_end(self, ctx, agent, tool, result):
        metrics.histogram("tool.latency").observe(elapsed)
    async def on_handoff(self, ctx, from_agent, to_agent):
        audit.log(f"handoff {from_agent.name} -> {to_agent.name}")

agent = Agent(name="triage", hooks=[AuditHooks()])

缺口同样明显：只有 on_llm_start，没有 on_llm_end。这意味着你拿不到单次模型调用的真实墙钟延迟，成本/延迟归因只能退回去数 token 反推，误差在长上下文场景下可达两位数百分点。其次是无短路能力——on_tool_start 不能返回一个结果跳过真实工具执行，护栏必须另走 Guardrails 接口，钩子层做不了拦截。变现上，这套双轨 API 极适合做"合规审计训练营"（官方文档已有 AgentHooks/RunHooks 做审计链的范例），但必须向学员交代 on_llm_end 的补齐方案。

四、LangGraph：回调面最全，但它是观察者不是控制器

LangGraph 继承自 LangChain 的 BaseCallbackHandler，提供 on_llm_start/on_llm_end/on_tool_start/on_tool_end/on_chain_start/on_chain_end 等成对回调，是六框架里前后成对最完整的。它的真正护城河是 CallbackManager 默认隔离异常：你的回调抛 KeyError，框架吞掉并继续，agent run 不会因为一个埋点 bug 崩掉——这是生产环境极其珍贵的韧性。

from langchain_core.callbacks import BaseCallbackHandler

class TraceHandler(BaseCallbackHandler):
    def on_llm_start(self, serialized, prompts, **kw):
        metrics.timer("llm").start()
    def on_llm_end(self, response, **kw):     # LangGraph 有，OpenAI 没有
        metrics.timer("llm").stop()
    def on_tool_end(self, output, **kw):
        metrics.histogram("tool.out_len").observe(len(str(output)))

代价是它只有观察权，没有控制权。回调不能改写返回值、不能短路流程——所有控制流必须建模进图节点。这在简洁场景是优点（关注点分离），但在需要"钩子里改行为"时就是税：你要为每个拦截点单独画 node。另一缺口是 handoff 没有原生钩子（LangGraph 的交接本质是节点边），多智能体治理要自己在 node 里埋点。变现角度，LangGraph 最适合做"复杂工作流编排 + 全链路追踪"产品，但训练营门槛偏高，受众偏资深。

五、CrewAI：粗粒度陷阱，LLM 与工具揉成一团

CrewAI 的钩子面是六框架里最薄的：step_callback（每步后触发）和 task_callback（每任务后触发）。问题在于"步"这个粒度太粗——一次 step 可能内含一次 LLM 调用加若干工具调用，三者被打包成同一个回调事件，无法区分。

crew = Crew(agents=[...], tasks=[...],
            step_callback=lambda step: log.info(step))  # 拿不到 LLM/tool 边界

这导致三个直接后果：(1) 成本归因失真，无法把 token 花销精确落到"是模型贵还是工具多"；(2) 护栏无附着点，tool_start 前拦截根本无从谈起；(3) 它是同步回调，每次 step_callback 里做一次 50ms 的 tracing 上报，会串行阻塞整个 crew。覆盖率 2/7 的本质是"设计哲学优先角色协作，而非可观测性"。CrewAI 适合做"团队编排层"叠加在 LangGraph 执行引擎之上（业界已有这种混合实践），但作为生产内核，它的钩子面需要外部补丁。变现上 CrewAI 是上手机器、训练营变现快的标的，但必须诚实标注其生产观测短板。

六、Google ADK：最规整的对称设计，但能短路就是 footgun

Google Agent Development Kit（ADK）给出六框架里最对称的钩子命名：before_agent_callback/after_agent_callback、before_model_callback/after_model_callback、before_tool_callback/after_tool_callback。前后成对、命名自解释，6/7 覆盖率仅次于其规整度。

from google.adk.agents import LlmAgent
from google.adk.models import LlmRequest, LlmResponse

def before_model(cb_ctx, req: LlmRequest):
    metrics.timer("model").start(); return None          # 返回 None → 继续
def after_model(cb_ctx, req, resp: LlmResponse):
    metrics.timer("model").stop(); return None
def before_tool(cb_ctx, tool, args):
    if tool.name == "delete_db": return block_resp()     # 返回 Content → 短路！
    return None

agent = LlmAgent(name="A",
    before_model_callback=before_model, after_model_callback=after_model,
    before_tool_callback=before_tool)

ADK 是唯一钩子可以短路改写的主流框架：before_* 返回 None 放行，返回一个 Content 则跳过真实执行直接采用该结果。这既是杀手锏（护栏、A/B、注入测试用例全在钩子里完成），也是 footgun——一个 before_model 里意外返回非 None，整个推理就被静默替换，调试极难。此外 ADK 钩子异常不隔离，会传播并杀掉 run。变现上，ADK 的短路能力是做"可插拔护栏/红队注入"产品的天然底座，价值密度最高，但工程纪律要求也最高。

七、AutoGen v0.4 与 PydanticAI：两种事件范式之争

AutoGen v0.4 重构为事件驱动，提供 AgentHooks（on_start/on_end/on_message_received/on_message_published/on_reset）加工具级 before_call/after_call。它是消息中心的——钩子主要绑在消息收发上，对单次 LLM 的前后细粒度较弱（4/7），更适合对话式多智能体的治理与去重。

PydanticAI 走的是显式事件流路线：你用 agent.iter() 得到一个异步迭代器，主动 async for 消费 PartStartEvent、FunctionToolCallEvent、FunctionToolResultEvent。这种范式把"埋点"从回调注入变成了显式消费——好处是异常天然隔离（你的消费循环崩了不影响 agent 内部）、无回调地狱；代价是你必须主动跑这个迭代，不能用"配一个全局 handler 就完事"的姿势。两者都达到 6/7 覆盖率，但接入心智模型截然不同：AutoGen 是"注册回调"，PydanticAI 是"读流"。

async with agent.iter(user_prompt=q) as run:
    async for ev in run:
        if isinstance(ev, FunctionToolCallEvent): metrics.inc(ev.tool_name)
        elif isinstance(ev, FunctionToolResultEvent): metrics.observe(lat(ev))

八、三笔隐藏税：顺序阻塞、异常逃逸、归因盲区

把六框架放进同一套基准压测，钩子的真实代价收敛为三笔可量化的税。顺序阻塞税：同步内联钩子（CrewAI、ADK 未隔离路径）会让每次埋点的 I/O 串行挂在 agent 循环上；一个含 5 次工具调用的 run，若每次回调做 50ms 远程 tracing，CrewAI 累计阻塞约 250ms 纯开销，而 LangGraph/PydanticAI 的异步/独立迭代不阻塞主循环——同样的可观测性，账单差一个数量级。异常逃逸税：一个有 bug 的 on_tool_end 抛异常，在 OpenAI/ADK 里整个 run 当场崩，用户看到 500；在 LangGraph 的 CallbackManager 与 PydanticAI 的独立迭代里被吞掉，run 正常完成、埋点静默失败——后者用"可观测性降级"换"主流程存活"，是更对的工程默认值。归因盲区税：缺 on_llm_end（OpenAI、AutoGen）意味着 P50/P99 延迟只能靠 token 数反推，长上下文与流式首字延迟会被严重低估，最终成本曲线失真。

flowchart TD
    S([agent_start]) --> LS[llm_start]
    LS --> LE[llm_end]
    LE --> T{需要工具?}
    T -->|是| TS[tool_start]
    TS --> TE[tool_end]
    TE --> H{交接?}
    H -->|是| HO[handoff] --> LS
    H -->|否| L2{继续?}
    L2 -->|是| LS
    L2 -->|否| E([agent_end])
    T -->|否| H

    classDef ok fill:#d4edda,stroke:#28a745
    classDef gap fill:#f8d7da,stroke:#dc3545
    class S,E,LS,LE,TS,TE ok
    class HO gap

图中绿色为六框架普遍覆盖的事件，红色 handoff 是几乎全员缺口的盲区——多智能体治理在钩子层基本只能靠自定义补丁。

九、变现与训练营评估

钩子层是少有的"技术深度高 + 商业可包装性强"的交叉点。三个变现路径：(1)产品化——做一个跨框架的"可插拔钩子审计层"（统一七事件面，自动补齐 OpenAI 的 on_llm_end 与全员的 handoff 钩子），面向合规与成本监控，ADK 的短路能力可叠加护栏引擎；(2)训练营——"Agent 生产化"主题天然包含钩子、护栏、审计，ADK 与 OpenAI 双轨 API 代码量适中、出片快，CrewAI 因覆盖率低只能作为反例教学；(3)咨询——很多团队的痛点正是"生产环境看不到 LLM/工具边界"，钩子覆盖率审计是切入活。优先级：先做 ADK/OpenAI 的护栏与审计训练营变现（周期短），再沉淀跨框架钩子层产品。

十、按场景的推荐方案

一句话收敛：别按星标数选框架，按你需要的"七事件覆盖率 + 异常隔离 + 是否要短路"这三项选——钩子面决定了你的 agent 在生产里是"可观测"还是"裸奔"，而这笔账，迟早要付。