LangGraph 在生产环境里的真实边界：状态图适合什么、不适合什么
如果你的 Agent 需要跨多轮维护状态、有条件分支和人工审批节点，LangGraph 是当前最稳的选择之一。但它不是万能胶，简单线性流程用它反而增加认知负担。
不堆概念，只拆真问题：Agent 怎么不无限循环、RAG 怎么不胡说、本地模型怎么在消费级显卡上跑起来、多智能体怎么不互相打架。
每个分类都对应一套可复现的工程路径，不是新闻聚合，是拿来就能改的参考实现。
从 ReAct 到有界自主，讲清 Agent 的最小四件套与生产级护栏设计。
进入 →Cursor、Copilot、Claude Code、OpenCode，按真实工作流而非跑分做选型。
进入 →32GB 显存能跑什么、vLLM 与 llama.cpp 怎么选，消费级硬件方案实测。
进入 →Chroma、Qdrant、Milvus、pgvector 选型对比，检索不准先改切分再换库。
进入 →角色分工与编排拓扑，让多个 Agent 协作而不是互相制造噪声。
进入 →LLM-as-a-Judge、沙箱与权限最小化，先防住删库再谈智能。
进入 →合同处理、工业排产、跨境客服，看按效果付费的真实交付案例。
进入 →从 Python 工程到生产部署，按阶段拆好的路线与可跑通的项目清单。
进入 →不追每一个新模型，只挑对“写AI程序”这件事有实际影响的更新。
如果你的 Agent 需要跨多轮维护状态、有条件分支和人工审批节点，LangGraph 是当前最稳的选择之一。但它不是万能胶，简单线性流程用它反而增加认知负担。
一个终端里的开源编程 Agent 能做到 192K Star，说明开发者对“可控、可换模型、不绑生态”的需求远未被满足。实测接 Ollama 跑本地模型，日常补全和重构够用。
llama-server + TurboQuant + MCP 工具链，在 RTX 5090 上实现了接近可用的交互速度。关键不在模型本身，而在量化和上下文管理的组合方式。
如果只做原型，Chroma 零配置最省事；Apple Silicon 上 LanceDB 的 Rust 原生嵌入让冷启动明显更快；Qdrant 在过滤和混合检索上更完整。先看数据规模和使用场景，再谈“最强”。
max iteration cap、execution timeout、沙箱执行、deny-first 权限模型，这四样缺一个，Agent 在生产里就是一颗定时炸弹。先把失败边界画清楚，再让它自主。
合同助理在数小时内处理数万份合同、多智能体分工完成材料识别到法律文书生成。收费方式从订阅转向按结果交付，意味着程序要对业务结果负责，而不只是“可用”。
模型上下文协议解决的是智能体与本地数据、第三方服务连接碎片化的问题。对开发者的直接好处是：工具层可以复用，不用为每个 Agent 重写一遍对接逻辑。
覆盖基础概念、设计模式到生产部署，结构完整。但真正卡住新手的往往不是概念，而是“第一个能跑通的小项目”。建议边看边配一个真实场景去改。
CrewAI 以角色分工和最快上手见长，适合快速搭出协作原型；AutoGen 已被移入 maintenance，由 Microsoft Agent Framework 接班。选框架时，维护状态和迁移成本要和功能一起看。
Copilot 认知度 79%、工作场所使用率 21%；Cursor 使用率 12%，但在愿意为 Agent 工作流付费的开发者中占比更高。工具选型正在从“有没有 AI”转向“AI 能不能接管多文件任务”。
纯向量检索擅长语义相似，但对“A 和 B 是什么关系、跨文档的因果链”很弱。Graph-RAG 把知识图谱和向量库叠在一起，适合合同、供应链、合规这类关系密集型场景。
人工智能AI程序不是模型排行榜的搬运工。我们花时间在那些“看起来能跑、上线就崩”的缝隙里：Agent 的循环边界、RAG 的检索精度、本地部署的显存账本、多智能体的消息拓扑、评测集的自欺欺人。这里的每一篇内容，都尽量给出可复现的配置、可回滚的步骤和明确的“什么时候不该用”。
不是热度榜，是评论区里真正吵起来、并且吵出了结论的话题。
把需求写成规格、让编程 Agent 生成可运行代码，听上去很理想。现实是规格本身的歧义会被 Agent 放大，人类监督节点不能省。能用，但别当成“一句话上线”。
OpenCode、Goose、MiMo Code 在补全和单文件重构上已经够用，但在跨仓库、多步骤、需要理解隐含架构约束的任务上，付费工具仍然更稳。差距在缩小，但没有消失。
32GB 显存能跑 35B 级别的 MoE，但 Agent 场景下工具调用的往返、长上下文的 KV Cache、多轮记忆的拼接，比模型参数量更早把显存吃满。先算上下文预算，再选模型。
SWE-bench Verified 上头部模型分数很高，但 Berkeley RDI 已经指出一批主流 Agent benchmark 可以被“刷”到接近满分而不真正完成任务。看分数之前，先看评估方法和任务分布。
当任务可以清晰切成独立子任务、且子任务之间有明确的验收标准时，多智能体有增益。如果步骤强耦合、需要频繁共享隐式上下文，单 Agent 加好工具往往更稳。
订阅制下“偶尔出错”可以接受，按结果交付则要求程序具备可追溯的决策日志、可量化的验收标准和失败后的回滚能力。这反过来推动了评测与安全模块的前置。
挑了一些有具体信息量的评论，不是“学习了”那种。
LangGraph 的状态图确实稳，但文档里没强调 checkpoint 的存储成本。我们上了 Postgres saver 之后，长会话的表膨胀比预期快很多，建议一开始就把清理策略写好。
RTX 5090 跑 Qwen3.5-35B-A3B 的 188 tok/s 我复现了，但前提是上下文控制在 8K 以内。一旦把工具返回全塞进去，掉到 60 以下。上下文预算比模型选择更关键。
Chroma 做原型无敌，但数据过 50 万 chunk 之后过滤性能下降明显。后来换 Qdrant 加 payload 索引，同样的查询稳定在几十毫秒。不是 Chroma 不好，是场景变了。
“没有 max iteration cap 的 Agent 是炸弹”这句话太真实了。我们内部测试时一个循环跑了 40 分钟，烧掉几十美元 token。现在所有 Agent 默认硬上限 15 轮，超了直接停并报警。
Cursor 的 Composer 在多文件重构上确实比 Copilot 激进，但也会更频繁地改到你不想让它碰的代码。我的做法是开新分支让它跑，diff 里逐块 review，不直接 accept all。
CrewAI 上手是真的快，半天能搭出一个内容生产流水线。但角色一多，任务分配和结果合并就开始玄学。后来砍到三个角色 + 一个显式仲裁，反而稳定了。
LLM-as-a-Judge 做日常回归确实省人力，但我们发现 Judge 对“格式正确但语义错误”的输出给分偏高。后来加了一层规则断言专门抓关键字段，才把漏网率压下来。
OpenCode 接 Ollama 跑本地模型，日常补全和写脚本完全够用，关键是不用把代码发给云端。复杂重构还是切回 Cursor，但日常 70% 的编辑已经可以在开源工具里完成了。
MCP 工具接入标准化之后，我们内部三个 Agent 项目共用了一套工具层，维护成本降了很多。但权限一定要单独设计，读文件和生产库查询绝对不能共用一个信任级别。
按效果付费听起来很酷，但验收标准写不清楚就是灾难。我们做合同审查 Agent 时，花了比开发更多的时间去定义“什么算审对了”。技术之外，产品定义能力才是天花板。
微软 18 课适合建立框架感，但真正让我入门的是把其中一个 demo 改造成自己工作里的周报生成器。有真实输入输出，学起来快十倍。
Graph-RAG 在合同和供应链场景确实有效，但图谱的构建和维护成本要提前算进去。如果实体关系不复杂，纯向量加好的元数据过滤可能是更经济的起点。