面试官看了一眼我的 AI 项目架构图，突然停住了。
“你这个 Agent，每次都是调用旗舰模型？”
我点点头：“对啊，肯定得用地表最强的啊，效果好。”
他沉默了两秒，然后开口：“那意图分类、标题生成、JSON 修复、简单摘要，也全走 Opus？”
我开始有点心虚：“主要是为了稳定……”
面试官没说话，等了几秒，又问：“那如果哪天旗舰模型限流了呢？意图分类这种小任务，每个月烧掉的钱你算过吗？”
很多朋友第一次做 AI 应用都会踩这个坑：以为模型越强，系统越稳。实际上，生产环境里真正难的不是“选一个最强模型”，而是根据任务类型、成本、延迟、风险，把不同请求送到合适的模型上。
有个做智能客服的团队，花了三个月把 RAG 知识库从向量检索升级到混合检索，再加了一层 Reranker。上线前，工程师在本地测了几十条问题，感觉效果好了不少，于是就推了上线。
一周后，业务方反馈：“有些问题感觉还不如以前准。”
这句话最麻烦的地方，不是“效果变差了”，而是没人知道它到底有没有变差。旧版本质量是什么水平？新版本是哪类问题退步了？业务方说的“不如以前准”，是真退步，还是用户预期变高了？一查才发现，历史质量数据几乎没有。
很多 AI 应用早期都是这样：靠体感上线，靠体感判断好坏，靠体感决定改完之后是不是进步了。
这就像在黑盒里飞行。
很多 AI 应用的第一个版本都很“顺”：本地调通一个大模型 API，页面上能看到回答，Demo 就算跑起来了。
但一上生产，麻烦马上变得具体：
{"answer": "根因是。很多开发者第一次接大模型到业务系统里，都会经历一个很尴尬的阶段：本地 Demo 跑得挺顺，Prompt 里写一句“请返回 JSON”，模型也乖乖吐出一个对象；一到生产环境，问题就开始冒头。
有时它会在 JSON 前面加一句“好的，以下是结果”；有时少一个必填字段；有时本来应该是数字的 orderId 变成字符串；更麻烦的是，边界条件一复杂，模型会补出一个业务系统根本不认识的枚举值。解析器一报错，整条链路就断了。
问题不在于模型“不听话”，而在于我们把自然语言承诺错当成了工程契约。
第一次做企业知识库问答时，通常会经历一个很相似的阶段：文档切块、Embedding、向量库、Top-K 检索、把片段塞给大模型。
Demo 很顺，领导问几个制度类问题也能回答。然后业务同事突然问：
“这几个部门过去半年反复提到的风险点是什么？它们之间有什么关联？”
向量 RAG 就开始力不从心了。
它可能找到几个相似片段，却很难把“部门”“风险”“项目”“供应商”“时间线”这些对象串成一张关系网。更麻烦的是，答案往往来自多份文档的组合推理，而不是某一个 Chunk 里现成的一句话。
术语约定：本文中 "Chunking" 与“切分”、"Embedding" 与“嵌入”、"Chunk" 与“块” 含义相同，统一使用中文表述以保持可读性。
很多团队第一次搭 RAG 系统时，都会经历一个特别有意思的阶段：买最贵的向量数据库、调最牛的 embedding 模型、上线之后发现答案还是一塌糊涂。
根因往往不在检索环节，而在更上游——文档根本没有被正确解析，切分的时候把表格列拆散了，Chunk 把条件和结论切成两半，页眉页脚被当成正文入了索引。
第一个企业知识库 RAG 系统上线后，很多团队都会碰到一个很真实的问题：文档明明更新了，回答还是老样子。
这时候先别急着怪 LLM。更常见的原因是知识库没有同步更新，或者更新链路只做了“写入新内容”，没有处理旧版本、权限、索引一致性这些细节。文档变更频繁之后，问题会更明显：每次都全量重建索引，成本和耗时扛不住；只更新变化部分，又怕漏掉旧块；只插入新向量，不清理旧版本，过期内容还会继续被召回；换了 Embedding 模型，历史数据到底要不要全部重索引，也绕不开。
这些问题背后，其实是 RAG 知识库的动态性、准确性、一致性、可回滚、可观测这几件事没有处理好。
第一次做 RAG 时，很多人的体验都差不多：文档切了，向量库建了，Top-K 也调大了，模型还是一本正经地胡说八道。
更难受的是，问题可能出在文档解析、Chunk 切分、上下文质量等多个环节，而不是单纯的 embedding 或 Top-K 参数。
调一个企业知识库问答时，很容易陷入一个误区：一开始疯狂换 embedding 模型，结果线上错误率没明显下降。把失败样本拆开看才发现，60% 的问题根本不是向量相似度不够，而是 PDF 表格被解析坏了、Chunk 把条件和结论切开了、重排前的候选池里没有正确片段。
RAG 优化的第一条经验是：它本质上是数据、切分、索引、召回、重排、上下文、生成、评估共同组成的系统工程，不是单点调参。
刚上手 AI 工作流时，很容易有类似的困惑——这不就是传统工作流换了个壳吗？为什么不用 Camunda、Temporal 这些成熟引擎？甚至觉得把几个 Prompt 用 if-else 串起来就算“工作流”了。
但真正上手做项目后，这些想法很快会被现实打脸。LLM 的输出天然不确定，单次生成往往不达标，工具调用随时可能失败，上下文窗口还有硬上限。光“跑一遍就完事”的线性流程不够用，你需要的是一套能动态决策、自动修正、可控收敛的执行机制。
今天这篇文章就来系统梳理 AI 工作流中三个核心概念——Workflow、Graph、Loop，帮你建立从概念到实现的完整认知。本文接近 7300 字，建议收藏。通过本文你会搞懂：
别只盯模型。
很多人第一次做 Agent，直觉都是先买更贵的模型。结果模型换了，Agent 还是会重复犯错，做到一半放弃，上下文一长就开始不稳定。这个时候继续调 Prompt，收益往往也很有限，因为问题可能根本不在模型本身。
有个实验挺能说明这件事：同一个模型，只换了文件编辑接口的调用方式，编码基准分数从 6.7% 跳到了 68.3%。模型没有变，变的是它外面那套系统。也就是说，Agent 能不能稳定干活，很多时候取决于模型之外的环境、工具、反馈和约束。
最近 AI Agent 开发圈里经常提到一个词：Harness Engineering。它讨论的就是这件事：决定 Agent 表现上限的，可能不是模型，而是你给模型搭的那套工作环境。