「家里有数」的组织， AI 落地新三步走策略来了

老规矩先说结论：

之前我们讲，对广大家里「有数」的组织来说要分 RAG、Agent、FT 三步走引入 AI 落地，以下是更新过的建议行动方案(新三步走)：

1. 以文献为中心的数据治理（广义的 RAG 和 RLVR）
   1. 以高准确率为核心的检索、溯源系统
   2. 在可负担的权重尺寸下，用自有模型替换商用模型
2. 以 Claude Code subagents 为中心的新流程探索
3. 以 LangGraph 为中心的老流程自动化

先解释第二条，因为第二条最有意思：

之前我们说要先做 RAG 练手、再做微调试水、最后上 Agent 打通业务流程，到现在其实还是这三个步骤，不过侧重点要随着大模型能力提升调整一下：RAG 被大家摸透、开源大模型效果一直比前沿闭源大模型落后 9～12 个月（source: https://menlovc.com/perspective/2025-mid-year-llm-market-update/），我们只能 SFT + RLVR 训垂类小模型。

跟很多事情一样，Agent 开发的方法、路径有让人眼花的无数条，但真正适合每个人、每个单位的可能有且仅有一条，多了就会变成负担和技术债。说一下我们探索的路径，权当工作透明化的一个实践。

这个事情其实已经在很多场合说过多遍，为了应对高速发展的业界进展，我们需要有一套以快打快的方法论应对，说穿了其实很简单：「用类似 Claude Code Subagent 这种方式来应对日常突发的新任务，用 LangGraph 自动化固定流程的旧任务」（为什么要强调类似 CC？因为众所周知，Anthropic 的创始人当年在百度做实习生的时候不知道遭受了什么职场霸凌，对中国非常不友好，钱也不收，事儿也不合作，咱十几亿人口就这么被他拉黑了，当然人家不拉黑咱，咱自己也有能耐拉黑自己个，总之一个原则就是不让你用，double kill！）

把 Claude Code（简称 CC）视为一套通用的工具集而不是简单的代码生成工具，尤其是它的自定义指令和 subagent，为什么？有两个原因：

1. CC 的 subagent 定义完全是自然语言交互，全程无需一行代码，用起来跟领导交代忠心的下属做一件他做熟了的事一样，自然流畅，让用户的心智负担降到最低
2. 内置 Web Search 功能，Anthropic 家的 web search 跟别家不太一样，它把 web search 这种功能集成到了大模型的能力中（而不是其他家那样仅仅给一个 web search 的 function call 描述，当然如果你需要，Claude 也能给），这样做的好处就是，无论你的需求是什么，大模型都能通过 web search 从互联网上给你一个初步的解决方案，这个特性在很多事情的探索阶段非常之有用，可以低成本试错，快速找到正确的方向

其实 CC 不让用也不用太糟心，Qwen-code 、CodeBuddy、Google Gemini 这些都排着队免着费等你翻牌子，也都支持 subagent 或者类似的概念。只不过效果确实不咋滴，其他的比如 AMPCode、CodeBuff ，前者效果跟 CC 同属 S 级但收费也同属一级，后者商业化版本收费也不低，但好处是有开源社区版，天然亲和 openrouter，但问题是 openrouter 用久了也非常贵，所以思来想去，当前这个节点，还是搞点手段上个 Claude Max 版本的共用平台最靠谱（https://github.com/Wei-Shaw/claude-relay-service/），当然前提是你得有一个可以正常给 Anthropic 这帮二货付费的海外信用卡，或者虚拟信用卡（这个是啥我也不知道，而且建议你也不知道...)

再说第三条，针对已有的固有流程，原则上是能不动就不要动！原则上是能不动就不要动！原则上是能不动就不要动！

看起来跟第三条，以 LangGraph 为中心的「旧」流程自动化矛盾？其实一点也不，旧流程跟新流程不一样，不要老想着拿新瓶子重新装旧酒革丫的命，出出方案做做架构拿个晋升是可以的，真要动，除非同时满足以下两个条件：一把手全力支持、个人收益 double+，这两个条件缺一，你就等着掉坑吧。

想好了真要整的话这里是好处清单：

1. 我们之前也说过，LangGraph 背后的设计思想是从 NetworkX 来的，而 NetworkX 背后是有限状态机 FSM，这货天生就是为流程已经固化的工作流设计的，讲究一个所有状态都考虑到，状态之间的迁移完全 cover 住，这样一来你 debug、数据回朔甚至业务重放都能给你实现了，简直就是企业应用、居家旅行，xxxx 之必备！
2. 上面是纵向比较那么横向呢？跟 LangGraph 对标的方案有很多，其中就包括 OpenAI 自己的 Agent SDK，其他的比如 CrewAI、LLamaIndex 等等数不过来，跟这些对比，LangGraph 的优势是社区活跃且稳定、代码组织面向企业应用（意味着好招人）、有自己完善的数据监控（LangSmith）和云服务以及开发环境（LangGraph Studio）支撑

插播一个番外：

如果你根本没有「旧」业务，是不是直接上 LangGraph 就好，并不是！LangGraph 明显是更程序员一些，是让你的 Agent 更像机器一样的方案；而 CC，明显是让你的 Agent 更像人的方案，你猜这两个方案在探索新场景的时候哪一个更容易迭代？何况 CC 趟出来路，LangGraph 出来收钱也很顺理成章不是。

转回来说第一条，以文献为中心的数据治理

有人可能觉得这个老掉牙的话题为什么还要提？因为 ta 重要，因为 ta 核心！

一年前我们折腾 RAG，烂大街的场景就是 ChatPDF 对吧，到现在了，逢人必谈 Agentic 的时代，其实大部分依然或者的团队都在折腾自己的文档库，据说 90% 的 AI 团队会死掉，我猜剩下 20% 的团队现在都已经有了自己的一套数据治理流程，这事往小了说就是一个文档管理，往大了说就是数据治理，并没有区别。

虽然业界已经有了许许多多的 Saas 服务，但在看重数据安全的 2B 方向上大都用不了，包括但不限于这些：

• eyelevel.ai
• eventual.ai
• samay.ai
• reducto.ai
• zeroentropy
• nuextract.ai

为什么要把这一堆列出来？第一当然是为了显摆我看的东西多（删掉重写），第二是新鲜的思路其实不太会来自院校，基本都是来自企业，你想看到最新的思路，不看这些企业看啥呢？

大部分的 B 端企业和科研知识都以各种各样文档的方式存在，所以这第一步的信息留存率直接决定了后面各个环节的天花板高度。

目前的情况是，大部分方案仅仅提取了文字，还存在顺序不对、格式不对、断句接不上甚至页眉页脚信息没有剔除这种，很多商用方案都没有，更不用说多头表格、跨页面的表格、图片信息等等这些了。

总之这一部分一句话，任重道远继续投入继续跟就对了。

插播个 RLVR

我们这里把 RLVR 放到了 数据治理部分没有单列成一个章节，不是因为 RLVR 不重要，而是应该把它视为数据治理整个流程中的一个环节，一个机器验证的环节，理数据的时候顺便做了就好，怎么做？有什么机会？去看 Prime Intellect(https://www.primeintellect.ai/)

• 数据治理即环境
• 数据治理即 RLVR 大模型