在《手搓生产级 AI Agent 系统》系列中，我们已经覆盖了 Agent Runtime、Tool Calling、Memory、Planner、Checkpoint、多 Agent、安全、评测、Control Plane、Registry、Identity 与企业级治理等模块。上一篇实测了 DeepSeek Harness 桌面版，本篇进入一个更前置的问题：构建 AI Agent 时，工具链到底怎么选？
公开资料中有一篇深度文章专门对比了 LangGraph 和 Ollama 两个工具，并给出使用它们构建 AI Agent 的步骤。这是目前候选证据里唯一直接涉及工具选型的内容。需要先明确：LangGraph 和 Ollama 并不是同一层的竞品，把它们放在一起“二选一”本身就是一种常见的选型误区。
两者定位完全不同
Ollama 解决的是“模型从哪来、怎么跑”的问题。它面向本地推理场景，让开发者可以在自己的机器上拉取和运行大语言模型，不依赖外部 API。对于需要数据不出本地、离线运行或快速验证 Agent 行为的场景，Ollama 提供的是模型运行时能力。
LangGraph 解决的是“Agent 逻辑怎么编排”的问题。它关注的是如何把多个步骤、条件分支、工具调用和状态流转组织成一个可执行的 Agent 工作流。它不负责模型推理本身，而是负责调度和状态管理。
因此，正确的选型问题不是“选 LangGraph 还是 Ollama”，而是“我的 Agent 需要本地推理吗？需要复杂编排吗？”两个问题的答案可以同时为“是”。
选型考量维度
从生产级 Agent 系统的角度，选型至少要考虑以下几个维度：
推理位置：如果数据敏感、需要离线或想控制推理成本，Ollama 这类本地推理方案更合适；如果追求模型能力上限且可以接受网络调用，外部 API 仍是主流选择。
编排复杂度：如果 Agent 只是单轮问答加简单工具调用，轻量脚本即可；如果涉及多步骤规划、条件分支、循环、人工介入和状态持久化，LangGraph 这类图式编排框架的价值才会显现。
状态与检查点：生产级 Agent 需要 Checkpoint 能力来支持中断恢复和审计。编排框架是否原生支持状态快照，直接影响后续可靠性设计的难度。
可观测性：无论选哪个工具，都需要能追踪每一步的输入输出。本地推理方案在日志和指标采集上需要自行补齐，编排框架通常提供一定的执行轨迹能力。
部署与运维：Ollama 需要管理本地模型文件和硬件资源；LangGraph 作为编排层，需要与现有的服务治理、配置管理和发布流程集成。
组合使用的典型路径
公开资料给出的构建步骤暗示了一种常见组合：用 Ollama 提供本地模型推理，用 LangGraph 编排 Agent 流程。这种组合适合以下场景：
- 开发阶段快速迭代 Agent 逻辑，不消耗外部 API 配额；
- 对数据隐私有要求，模型推理必须在本地完成；
- 需要图式编排来表达复杂决策流程，同时希望模型层可替换。
需要注意的是，本地模型的推理能力和上下文窗口通常弱于云端大模型。公开资料也提到 AI Agent 存在执行偏差、上下文窗口受限等局限。因此，在本地推理方案上构建生产级 Agent 时，必须对任务复杂度做裁剪，并在评测环节重点验证失败模式。
工程建议
第一，先明确分层。把“模型推理层”和“Agent 编排层”分开评估，不要混为一谈。Ollama 属于前者，LangGraph 属于后者。
第二，从最小可运行闭环开始。无论选哪个工具，先用一个真实任务跑通“感知—决策—行动”循环，再逐步加入 Memory、Checkpoint 和工具调用。
第三，为替换留出接口。模型层和编排层之间应通过抽象接口通信，这样从本地模型切换到云端模型，或从一种编排框架迁移到另一种时，改动范围可控。
第四，把评测前置。选型阶段就应确定关键指标，例如任务成功率、单步延迟、工具调用准确率和恢复能力。没有评测的选型只是偏好。
第五，关注生产化缺口。公开资料对 LangGraph 和 Ollama 的介绍停留在构建步骤层面，未涉及企业级治理、身份认证和多租户隔离。这些能力需要在本系列后续的 Control Plane、Registry 和 Identity 模块中自行补齐。
小结
LangGraph 与 Ollama 的对比，本质是编排层与推理层的分工问题。生产级 AI Agent 系统通常两者都需要，而不是二选一。选型时应先拆解需求：推理放在哪里、编排复杂到什么程度、状态和可观测性要求多高。把这些问题回答清楚，工具选择自然清晰。下一篇将继续沿着系列路线，进入 Agent 系统的可观测性与评测环节。