从"调用API"到"编排工作流"：我搭建AI辅助开发链路的三个月

一篇偏技术的实践记录。不讲概念，只讲我踩过的坑、选过的方案、以及那些文档里不会写的细节。

背景与目标

三个月前我开始系统性地把LLM接入日常开发流程。目标很明确：不是"用AI写代码"，而是构建一条可复用、可观测、可控成本的AI辅助链路，覆盖代码生成、CRUD脚手架、单测补全、代码Review辅助和文档同步几个环节。

技术栈：Python/TypeScript为主，模型侧混合使用闭源API（GPT-4o/Claude）和本地部署（Qwen2.5-32B via vLLM），向量侧用pgvector，编排层最开始是脚本，后来迁到LangGraph。

下面按时间线讲。

第一阶段：朴素API调用，撞上三个墙

最开始的实现很直接：拼prompt → 调API → 解析结果。很快就遇到问题：

墙一：上下文窗口不是越大越好。 我一开始把整个文件甚至整个仓库的相关代码塞进prompt，结果token成本飙升，而且模型对中段信息的召回明显下降（典型的"lost in the middle"）。后来改成基于AST的精准切片：用tree-sitter解析出函数/类边界，只把目标符号及其直接依赖注入上下文。这一改动让平均token消耗降了约60%，输出质量反而更稳。

墙二：结构化输出不可靠。 早期靠正则从自然语言里抠JSON，失败率感人。切换到Function Calling / JSON Schema约束解码后基本解决。本地模型这边用vLLM的guided decoding（outlines后端），把schema直接编译成logits mask，结构化输出成功率接近100%。

墙三：没有评测就没有优化。 一开始凭感觉调prompt，改来改去不知道是变好还是变坏。后来搭了个最小评测集：50个真实任务（含输入、期望输出的关键特征），每次改prompt或换模型都跑一遍，记录通过率和token成本。这一步是整个项目最重要的基础设施，没有它后面全是玄学。

第二阶段：从单次调用到工作流编排

单点调用解决不了多步骤任务。比如"给这个模块补单测"，实际包含：读代码 → 识别分支和边界 → 生成用例 → 跑测试 → 根据失败反馈修正。这是个带循环的agent流程。

我选了LangGraph做编排，原因是它把状态机显式化了——节点、边、条件跳转都能画出来，调试时能回放每一步的state。对比过AutoGen和纯手写while循环：AutoGen偏多agent对话，对确定性流程反而累赘；手写循环在第三步之后就不可维护了。

关键设计：

• 每个节点职责单一，输入输出用Pydantic模型强约束，节点之间不共享隐式状态。
• 失败反馈闭环：测试失败时把stderr和失败用例回灌给生成节点，最多重试3次，超过则降级为人工介入。实测这个循环把单测通过率从约55%提到82%。
• 工具调用加沙箱：代码执行放在隔离容器里（gVisor），限时、限内存、断网。这不是洁癖，是必需——模型生成的代码什么都可能干。

第三阶段：成本、延迟与可观测性

链路跑通后，问题变成工程问题。

路由分层。 不是所有任务都值得上大模型。我做了个简单分类器：简单补全/格式化走本地Qwen，复杂推理和跨文件重构走Claude。按任务类型路由后，月成本降了约一半，P95延迟也下来了。

缓存。 对确定性高的请求（相同prompt+相同上下文）做结果缓存，key用prompt的规范化hash。命中率不高（约15%），但命中的都是高频重复场景，边际收益明显。

可观测性。 用OpenTelemetry给每次调用打trace：模型、token数、耗时、是否命中缓存、下游评测结果。接了Langfuse做可视化。没有trace的LLM应用等于黑盒，出问题根本没法定位是prompt、上下文还是模型本身的问题。

踩过的坑（文档里不会写的）

1. 温度设为0也不完全确定。 受batch和硬件影响，同一输入偶有差异。对需要严格复现的场景，得记录完整请求体而非只记prompt。

2. 上下文截断策略比想象中重要。 简单的"保留最近N条"在长对话里会丢掉关键的系统约束。我改成"系统prompt+关键约束永不截断，中间历史按相关性摘要压缩"。

3. 本地模型和API模型的prompt不通用。 同一套prompt在Qwen上表现和Claude差很多，尤其是few-shot的格式敏感性。得分别维护，别指望一套prompt打天下。

4. 评测集的分布漂移。 真实任务和最初构造的评测集慢慢对不上，通过率虚高。得定期用线上失败case回填评测集。

小结

三个月下来，最深的体会是：AI辅助开发的瓶颈几乎不在模型能力，而在工程化程度——上下文怎么切、输出怎么约束、流程怎么编排、效果怎么度量、成本怎么控。模型每半年换一代，但这套工程骨架是可以沉淀下来的。

下一步想试的是把评测集和CI打通，让prompt变更像代码变更一样走review和回归。这条路还长，欢迎有类似实践的朋友交流。