大家好 👋，我是 Moment，目前正在使用 Next.js、NestJS、LangChain 开发 DocFlow。这是一个面向 AI 场景的协同文档平台，集成了基于
Tiptap的富文本编辑、NestJS后端服务、实时协作与智能化工作流等核心模块。在这个项目的持续打磨过程中，我积累了不少实战经验，不只是
Tiptap的深度定制、编辑器性能优化和协同方案设计，也包括前端工程化建设、React 源码理解以及复杂项目架构实践。如果你对 AI 全栈开发、文档编辑器、前端工程化或者 React 源码相关内容感兴趣，欢迎添加我的微信
yunmz777一起交流。觉得项目还不错的话，也欢迎给 DocFlow 点个 star ⭐
上个月月底，我去参加了一场在深圳举办的线下聚会，现场人很多，几乎称得上爆满，分享具体讲了什么我其实没有认真听完，但有一个现象让我印象特别深。
我发现，现场已经有很多并非技术出身的人在真实地使用 AI 做开发，有人是产品经理，有人甚至没有完整的软件工程背景，但他们一样能借助 Claude Code、Cursor 这类 AI 编辑器，把一个产品从想法推进到可运行的形态。
只要你真正用过这类工具，你就会知道它们强在哪里，很多时候你不必先把所有代码写完，只要把问题、目标和约束说清楚，模型就能替你完成相当大一部分工作，它不光是在替你补几行代码，更是在把你的想法翻译成可执行的过程。
这件事带来的冲击其实很直接，不是只有程序员才能做产品了，而是谁更会拆问题、谁更会组织上下文、谁更会调度 AI，谁就更有机会把事情做成。
所以，真正需要警惕的从来不是 AI 会不会写代码，而是你是否还停留在只会发一个 chat.completions 请求、然后等它吐一段文本的阶段，因为当 AI 开始参与真实任务时，竞争点已经不再只是会不会调模型，而是你能不能把模型接进系统、接进流程、接进业务，最后让它稳定地把事做完。
也正因为如此，这套文档不会停留在教你调用一下 LLM API 这一层，它想解决的是更往前一步的问题，当 AI 不再只是聊天，而是真正进入你的产品、流程和工程系统里时，你到底该怎么设计它、约束它、组织它、编排它。
从会调模型到能改整条 Agent 链路
理想状态大概是，你不再满足于发完请求就收一段文本，而是能把一条真正可执行的 Agent 链路说清楚，别人问起来，你也知道该动哪一层、从哪下手改。
这里不会拿概念填空来凑篇幅，那些词你多半已经见过。更值得花时间的是落地之后一定会撞上的事，比如上下文该留什么、该砍什么，模型才既记得住关键信息，又不会被历史拖垮。工具怎么写、Function Call 怎么接，才能少空转、少胡编，多把事办完。结构化输出怎么定，业务里才能当真数据用，而不是靠正则和运气硬接。
再往后，中间件、护栏、运行时、上下文工程各自兜的是哪一类坑，MCP 这类协议又该摆在协作架构的哪一层。人机协同、多 Agent、Subagents、Handoffs、Skills、Router、自定义工作流，听起来多，其实都是在不同复杂度下选一条路。至于 CoT、ToT、GoT、ReAct、Plan-and-Execute、Reflexion、Self-Critic、LATS 这些名字，背下来没多大用，有用的是它们背后控制流怎么画、推理预算该多给还是该省。
章节一路跟下来，术语和框架名自然会熟，但更值得带走的是一种手感。某类任务该用简单的 Agent 循环还是上图式编排，某段流程要不要上人审、要不要拆角色，某一步老是失败时，该补护栏、补记忆、补工具描述，还是干脆换一套推理策略。能分清这些，比多记十个 API 名字实在得多。
真正花时间的是把系统搭稳
网上讲 AI 开发的内容已经很多，常见的却两头偏，一头概念讲得热闹，回到工程里不知道该动哪只手，另一头 demo 复制粘贴能跑，一进真实业务就开始散。
第一次把结果跑出来的时候，你往往还觉得挺顺。你很快会发现，真正难的从来不是让它第一次跑起来，而是：
- 为什么这个
Agent一到复杂任务就开始乱 - 为什么多轮之后上下文越来越脏
- 为什么工具明明接了，模型还是不会正确调用
- 为什么结构化输出看起来像
JSON，实际上却根本不稳定 - 为什么接了很多能力，系统却越来越难控、越来越难测、越来越难上线
这套文档想把这一串问号拆开来看。重点不单是让模型答得更聪明，而是让你看清一个能进生产环境的系统底下有几层、每层在扛什么，出事该往哪一层摸，而不是遇事就把锅甩给模型不够聪明。
如何学习
按章节顺序读就行，不是要你迷信目录，而是后面的例子会默认你已经看过前面的概念，跳太狠容易半路卡住。
开头一大段都在打基础，裸调模型哪里别扭、LangChain 在补什么、Function Call、消息结构、工具怎么接、先跑一个最简单的 Agent、再加上会话记忆和结构化输出。拆开看是很多篇，合起来就是在说一件事，模型是怎么被接进一条可执行的链路里的。
再往后会硬一些，主要对付"能跑"和"敢上线"之间的差距，中间件、护栏、运行时、上下文工程、MCP、人机协同、多 Agent，以及 Subagents、Handoffs、Skills、Router、自定义工作流之类。名字多，你不用全记住，先有个印象，知道这些多半是在管权限、管边界、管出事以后谁来兜底。
后面才轮到规划、反思、试探、回退这类话题。CoT、ToT、GoT、ReAct、Plan-and-Execute、Reflexion、Self-Critic、LATS 当几种不同的走法看就好，定义背了也没多大用。有用的是下面这些判断，心里过一遍比抄名词强：
- 什么场景下值得多给一点推理预算
- 什么场景下应该尽快落工具、少走内耗
- 什么任务适合先规划后执行
- 什么任务反而应该边做边修正
- 什么情况下多想一步是收益，什么情况下只是成本
快收尾的时候会把长期记忆和 harness 拉出来，把执行、状态、持久化、审计、可观测性这些零散提过的东西并到一块，方便你对照真实环境里一般长什么样。
整体就是这样，先把基础概念和常见拼法摸熟，再啃工程和协作里那些让人心里发虚的部分，最后在控制流和收尾方式上收个口。
适合谁、怎么读
你若是写 React、做业务、跟需求，模型 API 也碰过，却越来越觉得卡不在页面上，而在模型怎么接、工具怎么配、多步任务怎么串，这一路的写法就是按这个感觉排的。
做过聊天框、demo，想再往"能办事"那边挪一步，也会对上号。别人做出来的像助手，自己的还在一问一答里打转，这类落差在这里会当成工程问题拆，而不是甩一句模型不够聪明。
还有一种情况，文章东一篇西一篇看过，记忆、工具调用、Agent 都见过词，就是拼不出一张图。按章节往下翻，多半能把那些散点接回一条线。
读法上可以松一点，不必一次啃完。过完一章，想想自己项目里有没有同款糟心事，有的话最小改动可以先动哪一步。理论不用第一遍就全吃透，能慢慢把问题和章节里的招对上，就已经在读对路了。