「AI 转型是一号位工程」已经是行业共识，但共识之下有两个空白始终没被填上：认知层，一号位到底要懂 AI 到什么程度；执行层，哪些事必须他亲自做，哪些可以交出去。 文章按会上真实的讨论顺序展开：先记录分歧在哪、怎么收敛的，再提炼出三个可以带走的共识——用「Agent 是不是默认工作入口」验体感，用「定结果、给实权、做取舍」验 ownership。

最近密集地跟参加过一些 FDE交流会 聊过之后，有个 bug 越来越明显，我甚至觉得它是当前 AI 转型里最容易被漏掉的一环。这篇把当时的观察和几个真实案例整理出来，算是给自己，也给同行的人留个提醒。

Agent 变慢、答不准、token 烧得快，最自然的反应是「换个更强的模型」。但实测下来，这四个症状的根因往往在四个完全不同的层：架构、决策、生成、上下文。这篇文章把每个问题拆成「怎么判断 → 常见根因 → 按代价排序的解法」，并给出一套先看分布、再定位层、最后才动手的排查顺序。

用户说「你们这个有点慢」，你打开日志只看到一条 200 和三秒的耗时——不知道慢在检索、模型还是工具。这篇文章把 Agent 的观测拆成四个问题，画出能回答它们的数据模型（User / Session / Trace / Observation 四层），用一次真实执行的 run 树对上号，再对比 LangSmith 和 Langfuse 的部署方式与成本。

图不好测：状态在节点之间流动、checkpointer 让第二次跑可能接着上次、全链路又慢。这篇文章把测试拆成三层——整图端到端、单节点当纯函数、用 updateState 只跑中间一段。顺带用一个反直觉的实测纠正一个流传很广的说法：污染测试结果的从来不是共享 graph 实例，而是共享 thread_id。

续跑、人审、时间旅行，三个能力背后是同一件事：状态被搬出了进程内存。这篇文章讲清 checkpoint 存什么、存在哪、谁决定粒度，以及为什么 MemorySaver 不能上生产。

createAgent 适合标准 agent loop，LangGraph 适合你自己设计的拓扑。分界线不在「简单或复杂」，在「流程的形状由谁决定」。附条件边回退、checkpointer 中断恢复两个可跑实验，以及一份什么时候该往下走的判断表。

差的不是技术栈，是一个约束：输出不确定。

大多数人学 Agent 框架，是从“中间件”这个词开始卡住的。

对应问题：9（Agent 效果怎么评、指标、测试集、badcase 回流）