FDE 这个词最近在 AI 应用开发圈子里频繁出现。它不是新框架也不是某个模型而是 Forward Deployed Engineer 的缩写翻译过来是“前线部署工程师”更直白一点说就是长期待在业务现场亲手把 AI 能力落地的工程师。很多团队找 FDE不是为了研究论文也不是为了做个 Demo而是希望有人能基于 LangChain、Harness、Skills、RAG 这些工具把一个真实业务问题从“模型能聊”推到“系统能跑、业务能用”。如果你正在做企业级 AI 应用落地或者已经用过 LangChain 做 RAG但总感觉缺一条完整的方法论这篇文章就是按我自己的实测和踩坑经验来拆的。我会先把 FDE 这个角色讲清楚再给一条从入门到企业级落地的路线最后补上 RAG 指标、Skills 编写、Harness 选型、常见排查链路这些硬细节。不用把 FDE 想得太玄它更像是一种把 AI 技术翻译成业务价值的能力组合。1. 先搞懂 FDE 到底解决什么问题1.1 FDE 不是新职位是 AI 落地的新分工FDE 这个概念最早出现在一些强调现场交付的技术公司里核心工作不是研发一个通用产品而是“带着产品和技术方案去客户现场把问题真正解决掉”。到了 AI 时代这个角色被重新放大因为大模型能力再强离企业业务还有一条很长的路内部知识库怎么接、工具怎么调、权限怎么控、输出怎么验收、失败怎么兜底。传统分工里算法工程师负责训练和微调模型后端工程师负责接口和数据前端工程师负责交互页面。但 AI 应用落地时最需要的是一个人能把模型、工具、知识库、流程和业务反馈串成一条闭环。FDE 就是干这件事的人。他不一定在某个环节最深但一定最清楚“整条链路怎么跑通”。这也解释了为什么 FDE 相关的热搜词里经常和 LangChain、Harness、Skills、RAG 绑在一起。因为这些不是单一功能而是 FDE 常用的四类技术工具。实际工作中FDE 更像是“用工程手段让模型更可信、更有用、更可控”的人。1.2 FDE 和提示词工程师、算法工程师、前端工程师的区别很多人容易把 FDE 和提示词工程师搞混。提示词工程师的重点是设计 prompt让模型输出更稳定FDE 的工作远不止 prompt还要处理工具调用、知识库、权限、日志、异常恢复和部署上线。和算法工程师比FDE 不需要自己训练模型但需要理解模型的边界知道什么时候该用 RAG什么时候该用工具什么时候该让模型直接回答。和前端工程师比FDE 也会写界面但界面只是整个应用的一层壳背后还连着 Agent 服务、向量库、模型网关和监控系统。我见过不少团队招“AI 应用开发工程师”实际做的工作就是 FDE。他们要处理企业微信机器人、内部文档问答、工单自动分类、知识库助手这些场景。看起来每个需求都不难但真正落地时各种边界条件和业务规则会让人头大。FDE 的价值就在这里能把这些杂乱的业务规则翻译成稳定的系统流程。1.3 FDE 的日常工作边界以我做过的几个项目来看FDE 的日常工作大概覆盖这几块和业务方确认真实场景明确“能用”和“好用”的差距。设计 AI 应用的整体流程包括闲聊、知识库问答、工具操作三类任务。把 RAG 链路搭建起来包括文档处理、切片、向量化、检索测试。给 Agent 配置 Skills比如查订单、查库存、发邮件、写周报。处理模型输出不稳定的情况加入校验、重试、人工兜底。上线后观察日志和指标持续调整 prompt、切片方式和参数。这不是一个线性过程更像是在业务反馈里不断迭代。FDE 真正要解决的核心问题不是“模型聪明不聪明”而是“模型能不能在真实业务约束下稳定完成任务”。2. 拆开 FDE 的技术底座LangChain、Harness、Skills、RAGFDE 常用技术栈可以分成四块。很多人一开始会一个个学但实际项目里它们是耦合在一起工作的。建议先理解每一块解决了什么问题再考虑怎么组合。2.1 LangChain 负责编排LangGraph 负责状态化流程LangChain 的核心价值是“编排”。一个 AI 应用通常不是简单的一问一答而是需要做多步处理先判断用户意图再决定调用哪个工具把工具结果拼进上下文最后生成答案。LangChain 能把这些步骤组织成一条链减少自己重复写胶水代码。但 LangChain 的线性链在处理复杂 Agent 时会遇到限制。比如循环、分支、条件跳转、人工介入这些流程用链条表达会很别扭。这时候就需要 LangGraph。LangGraph 可以理解成“带状态的流程图”每个节点是一个处理动作每条边是状态转移条件。它更适合做多步 Agent、人工审批、复杂业务流。我的选择经验是如果是固定流程、线性问答LangChain 够用如果流程里有分支、循环、多轮工具调用尽早用 LangGraph。不要为了“新”而上 LangGraph也不要因为“熟”而一直用 Chain 硬撑。判断标准就是流程是否需要状态管理和条件路由。2.2 Harness 负责工程化外壳模型和工具都往里塞Harness 这个词在 AI Agent 领域越来越常见。你可以把它理解成一个“可控执行外壳”模型在这个外壳里调工具、接收反馈、继续决策。常见的实现包括一些开源 Agent 框架以及 DeepSeek Harness、Codex Harness 这类社区工具。Harness 解决的核心问题是“失控”。如果直接把模型接到数据库、文件系统或外部 API 上模型只要多调一次参数或者按错误格式输出系统就崩了。Harness 会在模型和真实执行环境之间加一层规范层包括工具注册哪些函数可以被模型调用。参数校验模型生成的参数是否符合类型和取值范围。执行权限哪些操作允许自动执行哪些需要人工确认。日志记录每次工具调用的输入、输出和耗时。失败回退工具异常时模型应该怎么继续。选择 Harness 时我一般先看三点支持多少种工具类型、日志是否完整、能不能限制并发和权限。不用被概念吓住本质上它就是给 Agent 做了一层“安全护栏”。2.3 Skills 负责把能力固化让 Agent 可复用Skills 是最近被讨论很多的概念。简单说Skills 就是把“某个具体任务的提示词、参数定义、处理逻辑、输出格式”打包成一个可复用模块。比如“查订单状态”可以是一个 Skill“生成项目周报”也可以是一个 Skill。好的 Skills 有几个共同特点名称清晰模型看一眼就知道什么时候该用。描述准确写清楚这个 Skill 适合什么场景不适合什么场景。参数定义稳定字段名、类型、是否必填都要明确。返回结构固定方便后续流程继续处理。我见过很多 Skills 写不好问题通常不是提示词不够长而是描述太含糊。模型不知道这个 Skill 是干嘛的自然就不会触发。社区里也有现成技能包比如一些开源 Skills 库但直接拿来用之前一定要先测一遍看看描述是否符合自己的业务习惯。每个业务的“订单”“客户”“项目”含义都不一样不调过的 Skills 很容易误触发。2.4 RAG 负责知识库解决模型记不住业务细节的问题RAG 是检索增强生成。它的基本思路是用户提问后先从知识库里检索相关内容再把检索结果和问题一起交给模型生成答案。这样可以避免让模型死记业务文档也可以方便知识更新。一个完整的 RAG 链路包括文档加载把 PDF、Word、Markdown 等转成纯文本。切片把长文档切成合适长度的片段。向量化用 embedding 模型把文本变成向量。存储把向量和原文存进向量数据库。检索根据用户问题召回最相关的片段。生成把片段和问题拼成 prompt交给大模型回答。RAG 做得不好很多问题不在“检索”环节而在前面的切片和清洗。如果文档里有表格、扫描件、页眉页脚直接切片会导致内容残缺。FDE 需要花大量时间处理数据质量而不是只调向量数据库参数。更进阶的方向是 Agentic RAG也就是把检索过程本身交给 Agent 决策。比如先判断用户问题需不需要查知识库再决定查哪个知识库最后结合多轮反馈重新检索。这个方向适合知识库数量多、业务规则复杂的场景但复杂度也会明显上升。新手不建议一上来就做 Agentic RAG先把基础 RAG 的召回质量做到稳定再说。3. 从零到一一个 FDE 的最小实战路径如果你刚接触 FDE我建议按下面这条路径走不要一上来就搭企业级架构。先把最小闭环跑通再逐步加复杂度。3.1 环境准备什么配置适合学习FDE 学习阶段不需要太高的硬件条件。如果你打算完全用大模型 API那普通笔记本就够内存 16G 以上更舒服。如果你要跑本地开源模型就要重点看显存和内存。我实测下来一个 7B 到 14B 规模的开源模型量化后在 8G 显存左右可以勉强跑但推理速度不会太快也尽量不要同时开多个任务。如果只有 CPU建议直接选更小的模型或者用 API 完成前期学习否则大部分时间会花在等待推理结果上。还有个容易被忽略的配置是磁盘空间。embedding 模型、向量库、多个模型文件叠在一起几十 G 空间很常见。别等跑一半发现磁盘满了再去清理。3.2 先做一个不带 RAG 的问答链路第一步我建议先做最简单的问答链路用户输入问题模型返回答案。这一步不是为了炫技而是为了确认环境、依赖和模型调用都正常。很多新手一上来就做 RAG结果报错之后根本分不清是模型问题还是检索问题。一个最小示例的代码结构通常长这样from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI prompt ChatPromptTemplate.from_template(你是企业内部的客服助手请简洁回答问题{question}) llm ChatOpenAI(modelgpt-4o-mini) chain prompt | llm answer chain.invoke({question: 请问年假怎么申请}) print(answer)注意这里用了 LangChain 新版常见写法但实际包名和版本可能不同。如果导入报错先检查 LangChain 版本和依赖别急着改代码。跑通之后验证三件事输入输出是否正常、连续调用是否稳定、模型是否能准确理解你写的 prompt。3.3 给链路加 RAG问答链路稳定后再加 RAG。我建议先拿一小批文档做测试比如 10 到 20 篇业务 FAQ验证整个链路能通。RAG 代码的常见结构如下from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma loader TextLoader(faq.txt) documents loader.load() splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap100) chunks splitter.split_documents(documents) embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(chunks, embeddings) retriever vectorstore.as_retriever(search_kwargs{k: 4})然后把检索器和问答链拼起来from langchain.chains import RetrievalQA qa RetrievalQA.from_chain_type( llmllm, retrieverretriever, return_source_documentsTrue ) result qa.invoke(年假怎么申请) print(result[result]) print(result[source_documents])这里最关键的不是代码而是判断召回质量。你要去看检索出来的结果是不是用户真正需要的内容。如果召回结果不对先检查切片大小、重叠长度和文档清洗方式不要急着换向量数据库。3.4 把 Skills 加进来RAG 能让模型回答知识库问题但很多业务场景不只是“问答”还要执行动作。比如查订单状态、创建工单、发送审批。这时候就要给 Agent 加 Skills。Skills 的写法各家平台不完全一样但核心结构通常包含名称、描述、参数和逻辑。一个示意配置长这样{ name: query_order, description: 根据订单号查询订单当前状态和物流信息。只在用户询问订单状态时使用。, parameters: { order_id: { type: string, description: 订单号通常为字母或数字组合, required: true } } }写好的 Skills 要注册进 Agent再测试“模型是否能正确触发”。测试时我会故意用不同的说法问同一个问题比如“我的订单到哪了”“帮我看看 12345 这个单子”观察模型是否能调用同一个 Skill。如果触发不准确问题大概率在 description 写得太宽泛或太具体。要训练模型按规则触发本质是让描述和真实业务场景贴合。3.5 把 Harness 用起来当你有多个工具、多个 Skills 之后就需要 Harness 来管理执行过程。Harness 解决的是“模型乱调工具工具没返回消息后怎么处理”这类问题。实际使用 Harness 后你会看到更清晰的执行日志用户问题是什么。模型决定调用哪个工具。工具返回了什么。模型如何基于返回继续生成。最终答案是什么。我建议在切换 Harness 后先用已有的 RAG 和 Skills 案例完整跑一遍重点看日志是否完整、参数校验是否生效、失败时能不能回退。这些能力在 Demo 阶段不一定需要但到了企业级应用里没有日志和回退机制线上问题会非常难查。4. 从 Demo 到企业级FDE 的工程化框架很多人把 RAG 和 Agent 的 Demo 做出来之后下一步就不知道怎么办了。实际上从 Demo 到企业级落地并不是把代码搬到服务器上那么简单而是要把稳定性、权限、监控、失败重试这些工程问题一起补上。4.1 系统架构怎么分层企业级 AI 应用不适合把所有逻辑写在同一个脚本里。常见分层方式是客户端层网页、企业微信、钉钉、APP。接入层统一 API 网关负责鉴权、限流、日志。Agent 服务层接收用户请求解析意图调用模型和工具。知识库层向量数据库、文档索引、内容审核。模型层大模型 API 或本地模型服务。工具层订单系统、CRM、ERP、邮件系统等真实业务接口。FDE 要负责的是服务层到工具层这一段而不是只写一个模型调用函数。每一层的边界要清晰尤其是工具层不能把数据库账号直接暴露给模型调用。真实企业环境里工具调用都要经过权限校验和审计。4.2 接口设计与任务队列如果你的应用只是单用户测试同步调用没问题。但企业级应用通常需要支持多用户并发这时候就要考虑同步还是异步。同步接口适合耗时短、结果即时返回的场景比如普通问答。异步接口适合耗时长、流程多的场景比如批量文档总结、多轮 Agent 审批。异步任务一般需要一个任务队列把请求先接住再慢慢执行。任务状态要包括排队中、执行中、成功、失败、超时。用户可以通过任务 ID 查询结果。这里最容易踩的坑是“任务丢失”。如果没有持久化队列服务重启后排队中的任务会全部丢光。最开始可以简单用关系数据库存任务状态后续再换成更专业的消息队列。4.3 稳定性与可观测性AI 应用的稳定性问题比传统应用更棘手因为模型输出本身有随机性。同一个问题可能这次回答好下次回答差。所以必须靠日志和指标持续观察。建议至少记录以下内容用户请求内容。最终返回内容。模型调用耗时和 token 消耗。工具调用次数和每次结果。prompt 命中哪个版本。RAG 检索了哪些片段。是否有重试、是否有人工兜底。除了日志还要有链路追踪。因为一个请求可能经过模型、向量库、工具服务多个环节没有 trace 根本定位不了问题。好在很多 LangChain 和 Harness 工具已经提供了中间状态输出落地时把它们接入日志系统就行。4.4 安全与权限企业级 AI 应用的安全路径要提前想好不能等上线后再补。重点关注几类问题工具调用权限哪些工具允许模型自动执行哪些必须人工确认。数据访问权限不同用户能访问哪些知识库不能把 A 部门的资料召回给 B 部门。数据脱敏日志里不要记录手机号、身份证号、账号密码。输出审计模型生成了什么内容谁在什么时间看到了什么都需要留痕。FDE 在安全上的角色不是去实现安全算法而是把权限规则嵌入到 Agent 流程里。比如模型要查询客户信息前先经过一个权限判断节点不满足条件就直接拒绝不把底层数据暴露给模型。5. 用指标和验收清单判断结果好不好企业级 AI 应用不能只说“效果不错”要能定义指标、能验证、能回归。不同场景需要不同指标下面几个是 FDE 实际项目里用得比较多的。5.1 RAG 知识库指标怎么理解很多人做 RAG 只关心“看起来答得对不对”但上线前必须量化。常见指标有指标含义实际解读召回率应该召回的相关文档是否被召回了低说明切片、embedding、检索策略有问题精确率召回的文档里真正相关的比例低说明无关内容太多需要调重排序或降 kMRR第一个正确答案排在结果列表中的位置反映排序质量越高越好引用准确率答案引用的知识片段和业务文档是否一致防止模型自己编造引用上线前必查这些指标不是调一次就结束。业务文档更新后指标可能下降。所以最好建立一套测试集每次改动都跑一遍回归。5.2 Agent 技能成功率Skills 不能只看“能不能调用”还要看“调用后任务是否成功”。我一般分三个粒度看触发准确率该触发时触发不该触发时不触发。参数完整率参数是否齐全、类型是否正确。流程完成率调用工具后是否能完成后续生成或步骤。这三个指标会互相影响。参数不完整流程完成率一定低。流程完成率低可能是模型对工具返回值理解不够也可能是提示词里没有说清楚下一步规则。5.3 生产环境性能指标上线后还要关注P95 延迟大多数请求的耗时要稳定不能忽快忽慢。并发上限多少用户同时使用时服务开始不可用。Token 消耗单个请求平均消耗多少批量增长后成本是否可控。失败率包括接口报错、超时、模型服务不可用。这些指标决定了你后期是调流程还是先扩资源。很多项目效果不错但上线后没人用就是因为延迟太高或成本太高。5.4 验收清单每一项新功能上线前我都会过一遍清单正常路径是否走通。用户换一种说法是否还能触发正确流程。超出边界时是否优雅拒绝。工具服务不可用时是否有兜底回答。日志是否完整能否定位问题。权限是否控制正确。召回结果是否带可溯源标识。这个清单不用一次到位但至少要覆盖正常、异常、边界三类情况。AI 应用最怕的就是只测正常路径上线后被一个无厘头问题打崩。6. FDE 实战常见问题和排查链路FDE 的工作里排查问题占很大比例。下面几个问题我几乎每个项目都会遇到给出通用排查顺序。6.1 模型输出乱跑工具参数不对先看模型是否真的理解了工具描述。排查顺序查看模型调用日志确认模型有没有选择正确工具。如果选择了正确工具再看参数是否有缺漏。如果参数不对通常要改 Skills 里的参数描述把必填字段和格式写得更明确。如果模型频繁调用错误工具检查工具 description 是否和其他工具重叠。不要一上来就换大模型。大部分参数不对问题是描述不清而不是模型不够聪明。6.2 RAG 召回一堆无关内容这是 RAG 最常见问题。排查链路先检查测试问题本身是不是包含太多无意义词汇。看检索出来最靠前的几个片段的相似度分数如果很低说明向量化效果不好。检查文档切片是否完整有没有把一句话拆成两半。检查 embedding 模型是否和业务语言匹配英文模型处理中文效果可能不稳定。如果基础检索没问题但最终答案差可以考虑加一层重排序在召回后精排。6.3 Agent 循环调用工具停不下来Agent 出现死循环通常是工具返回的结果没有让模型获得“足够的新信息”。排查顺序看原始问题是什么。看每次工具调用返回了什么。如果工具返回内容太复杂或太简单模型可能判断不了下一步。设置最大迭代次数不能无限循环。在提示词里补充明确的终止规则比如“当用户不需要更多操作时直接给出总结”。6.4 本地 Harness 起不来或系统差异Harness 这类工具迭代很快系统差异和依赖冲突很常见。排查顺序确认 Python 版本是否在要求范围内。确认是否缺少系统级依赖比如某些库在 Linux 上需要额外编译。查看启动日志最后几行通常真正报错原因在最下面。翻一下工具的 release notes看最新版本是否有问题。实在不行就降级到上一个稳定版本不要一直在 main 分支上挣扎。6.5 依赖版本冲突和模型兼容LangChain 生态里依赖冲突几乎是每天都要面对的事。一个常见场景是 LangChain 核心包和第三方向量库版本不匹配导致某个类突然导入不了。我的排查顺序是记录当前环境的依赖版本列表。看报错指向哪个包优先去对应项目的变更日志。不要一次性升级所有依赖先固定核心包版本。如果项目不是特别复杂可以直接建一个干净虚拟环境重新装依赖装完再逐步加包。模型兼容问题也很常见。有些提示词格式只适合特定模型换一个模型后输出就变了。所以生产环境一定要固定模型版本至少固定模型名称和参数不能“默认最新版”。7. 想转 FDE 的工程师我建议先做这几件事这个方向听起来很宽但入门和进阶其实有明确路径。我给几个比较实际的建议。7.1 找到一个能天天摸到真实反馈的场景FDE 需要极强的业务感知能力。如果你只是自己在测试环境里跑 LangChain很难知道真实用户会怎么提问。建议找一个真实场景比如给团队内部做一个文档问答工具或者给某个业务部门做一个自动化工单助手。哪怕很小只要有人用你就能拿到真实反馈。用户问的问题会五花八门“这个文件为什么显示乱码”“为什么周报没有统计上周数据”。这些问题听起来不像 AI 问题但恰恰是 FDE 要解决的核心问题。真实反馈比任何教程都更能逼你成长。7.2 不要同时学十个框架先吃透一条链路LangChain、LangGraph、各种 Harness、不同向量库新手很容易东看一个西学一个最后什么都没深入。我更建议先固定一条链路LangChain 一个向量库 一个模型 API 一个 Harness把从文档导入到 RAG 检索再到 Skills 调用的完整流程跑通。然后再考虑要不要换 LangGraph要不要换更专业的 Harness。技术选型不是第一步先确认自己能把问题解决才有资格谈选型。7.3 把每次排查沉淀成 Skills 或模板FDE 的成长不是靠背教程而是靠积累排查经验。每次解决一个问题都可以想想能不能沉淀成一种固定处理方式。比如“遇到长文档检索不准先做数据清洗再调参数”这本身就是一个 Practice。写 Skills 也是这样。团队里经常有人问同样的问题你就可以把这个问题的回答逻辑写成一个 Skill。下次用户再问Agent 能自动处理。FDE 的长期价值就是不断把重复工作固化成自动化能力。7.4 保持对业务结果敏感最后一点FDE 不是只写代码的人。你要关注这个 AI 应用上线后是不是真的帮用户省了时间。如果 RAG 工具有人用但没人信任说明引用准确率不够如果 Agent 工具调用频繁失败说明流程设计有问题。我习惯每个迭代都问自己一句这个功能上线后业务方会怎么评价如果答案是“没什么感觉”那就说明需求没抓准。技术指标再好业务反馈差项目依然会失败。踩过几次坑之后我发现FDE 真正难的不是学会某个模型或框架而是能在复杂业务里保持判断力哪些问题值得自动化哪些问题必须人工处理哪些数据要先清洗哪些流程要先简化。技术工具会不断换但这条判断力才是长期积累的核心竞争力。 
长河君 · 2026/9/1 11:12:27 · 阅读 1.2k FDE实战指南：从LangChain到RAG的企业级AI落地方法论
FDE 这个词最近在 AI 应用开发圈子里频繁出现。它不是新框架也不是某个模型而是 Forward Deployed Engineer 的缩写翻译过来是“前线部署工程师”更直白一点说就是长期待在业务现场亲手把 AI 能力落地的工程师。很多团队找 FDE不是为了研究论文也不是为了做个 Demo而是希望有人能基于 LangChain、Harness、Skills、RAG 这些工具把一个真实业务问题从“模型能聊”推到“系统能跑、业务能用”。如果你正在做企业级 AI 应用落地或者已经用过 LangChain 做 RAG但总感觉缺一条完整的方法论这篇文章就是按我自己的实测和踩坑经验来拆的。我会先把 FDE 这个角色讲清楚再给一条从入门到企业级落地的路线最后补上 RAG 指标、Skills 编写、Harness 选型、常见排查链路这些硬细节。不用把 FDE 想得太玄它更像是一种把 AI 技术翻译成业务价值的能力组合。1. 先搞懂 FDE 到底解决什么问题1.1 FDE 不是新职位是 AI 落地的新分工FDE 这个概念最早出现在一些强调现场交付的技术公司里核心工作不是研发一个通用产品而是“带着产品和技术方案去客户现场把问题真正解决掉”。到了 AI 时代这个角色被重新放大因为大模型能力再强离企业业务还有一条很长的路内部知识库怎么接、工具怎么调、权限怎么控、输出怎么验收、失败怎么兜底。传统分工里算法工程师负责训练和微调模型后端工程师负责接口和数据前端工程师负责交互页面。但 AI 应用落地时最需要的是一个人能把模型、工具、知识库、流程和业务反馈串成一条闭环。FDE 就是干这件事的人。他不一定在某个环节最深但一定最清楚“整条链路怎么跑通”。这也解释了为什么 FDE 相关的热搜词里经常和 LangChain、Harness、Skills、RAG 绑在一起。因为这些不是单一功能而是 FDE 常用的四类技术工具。实际工作中FDE 更像是“用工程手段让模型更可信、更有用、更可控”的人。1.2 FDE 和提示词工程师、算法工程师、前端工程师的区别很多人容易把 FDE 和提示词工程师搞混。提示词工程师的重点是设计 prompt让模型输出更稳定FDE 的工作远不止 prompt还要处理工具调用、知识库、权限、日志、异常恢复和部署上线。和算法工程师比FDE 不需要自己训练模型但需要理解模型的边界知道什么时候该用 RAG什么时候该用工具什么时候该让模型直接回答。和前端工程师比FDE 也会写界面但界面只是整个应用的一层壳背后还连着 Agent 服务、向量库、模型网关和监控系统。我见过不少团队招“AI 应用开发工程师”实际做的工作就是 FDE。他们要处理企业微信机器人、内部文档问答、工单自动分类、知识库助手这些场景。看起来每个需求都不难但真正落地时各种边界条件和业务规则会让人头大。FDE 的价值就在这里能把这些杂乱的业务规则翻译成稳定的系统流程。1.3 FDE 的日常工作边界以我做过的几个项目来看FDE 的日常工作大概覆盖这几块和业务方确认真实场景明确“能用”和“好用”的差距。设计 AI 应用的整体流程包括闲聊、知识库问答、工具操作三类任务。把 RAG 链路搭建起来包括文档处理、切片、向量化、检索测试。给 Agent 配置 Skills比如查订单、查库存、发邮件、写周报。处理模型输出不稳定的情况加入校验、重试、人工兜底。上线后观察日志和指标持续调整 prompt、切片方式和参数。这不是一个线性过程更像是在业务反馈里不断迭代。FDE 真正要解决的核心问题不是“模型聪明不聪明”而是“模型能不能在真实业务约束下稳定完成任务”。2. 拆开 FDE 的技术底座LangChain、Harness、Skills、RAGFDE 常用技术栈可以分成四块。很多人一开始会一个个学但实际项目里它们是耦合在一起工作的。建议先理解每一块解决了什么问题再考虑怎么组合。2.1 LangChain 负责编排LangGraph 负责状态化流程LangChain 的核心价值是“编排”。一个 AI 应用通常不是简单的一问一答而是需要做多步处理先判断用户意图再决定调用哪个工具把工具结果拼进上下文最后生成答案。LangChain 能把这些步骤组织成一条链减少自己重复写胶水代码。但 LangChain 的线性链在处理复杂 Agent 时会遇到限制。比如循环、分支、条件跳转、人工介入这些流程用链条表达会很别扭。这时候就需要 LangGraph。LangGraph 可以理解成“带状态的流程图”每个节点是一个处理动作每条边是状态转移条件。它更适合做多步 Agent、人工审批、复杂业务流。我的选择经验是如果是固定流程、线性问答LangChain 够用如果流程里有分支、循环、多轮工具调用尽早用 LangGraph。不要为了“新”而上 LangGraph也不要因为“熟”而一直用 Chain 硬撑。判断标准就是流程是否需要状态管理和条件路由。2.2 Harness 负责工程化外壳模型和工具都往里塞Harness 这个词在 AI Agent 领域越来越常见。你可以把它理解成一个“可控执行外壳”模型在这个外壳里调工具、接收反馈、继续决策。常见的实现包括一些开源 Agent 框架以及 DeepSeek Harness、Codex Harness 这类社区工具。Harness 解决的核心问题是“失控”。如果直接把模型接到数据库、文件系统或外部 API 上模型只要多调一次参数或者按错误格式输出系统就崩了。Harness 会在模型和真实执行环境之间加一层规范层包括工具注册哪些函数可以被模型调用。参数校验模型生成的参数是否符合类型和取值范围。执行权限哪些操作允许自动执行哪些需要人工确认。日志记录每次工具调用的输入、输出和耗时。失败回退工具异常时模型应该怎么继续。选择 Harness 时我一般先看三点支持多少种工具类型、日志是否完整、能不能限制并发和权限。不用被概念吓住本质上它就是给 Agent 做了一层“安全护栏”。2.3 Skills 负责把能力固化让 Agent 可复用Skills 是最近被讨论很多的概念。简单说Skills 就是把“某个具体任务的提示词、参数定义、处理逻辑、输出格式”打包成一个可复用模块。比如“查订单状态”可以是一个 Skill“生成项目周报”也可以是一个 Skill。好的 Skills 有几个共同特点名称清晰模型看一眼就知道什么时候该用。描述准确写清楚这个 Skill 适合什么场景不适合什么场景。参数定义稳定字段名、类型、是否必填都要明确。返回结构固定方便后续流程继续处理。我见过很多 Skills 写不好问题通常不是提示词不够长而是描述太含糊。模型不知道这个 Skill 是干嘛的自然就不会触发。社区里也有现成技能包比如一些开源 Skills 库但直接拿来用之前一定要先测一遍看看描述是否符合自己的业务习惯。每个业务的“订单”“客户”“项目”含义都不一样不调过的 Skills 很容易误触发。2.4 RAG 负责知识库解决模型记不住业务细节的问题RAG 是检索增强生成。它的基本思路是用户提问后先从知识库里检索相关内容再把检索结果和问题一起交给模型生成答案。这样可以避免让模型死记业务文档也可以方便知识更新。一个完整的 RAG 链路包括文档加载把 PDF、Word、Markdown 等转成纯文本。切片把长文档切成合适长度的片段。向量化用 embedding 模型把文本变成向量。存储把向量和原文存进向量数据库。检索根据用户问题召回最相关的片段。生成把片段和问题拼成 prompt交给大模型回答。RAG 做得不好很多问题不在“检索”环节而在前面的切片和清洗。如果文档里有表格、扫描件、页眉页脚直接切片会导致内容残缺。FDE 需要花大量时间处理数据质量而不是只调向量数据库参数。更进阶的方向是 Agentic RAG也就是把检索过程本身交给 Agent 决策。比如先判断用户问题需不需要查知识库再决定查哪个知识库最后结合多轮反馈重新检索。这个方向适合知识库数量多、业务规则复杂的场景但复杂度也会明显上升。新手不建议一上来就做 Agentic RAG先把基础 RAG 的召回质量做到稳定再说。3. 从零到一一个 FDE 的最小实战路径如果你刚接触 FDE我建议按下面这条路径走不要一上来就搭企业级架构。先把最小闭环跑通再逐步加复杂度。3.1 环境准备什么配置适合学习FDE 学习阶段不需要太高的硬件条件。如果你打算完全用大模型 API那普通笔记本就够内存 16G 以上更舒服。如果你要跑本地开源模型就要重点看显存和内存。我实测下来一个 7B 到 14B 规模的开源模型量化后在 8G 显存左右可以勉强跑但推理速度不会太快也尽量不要同时开多个任务。如果只有 CPU建议直接选更小的模型或者用 API 完成前期学习否则大部分时间会花在等待推理结果上。还有个容易被忽略的配置是磁盘空间。embedding 模型、向量库、多个模型文件叠在一起几十 G 空间很常见。别等跑一半发现磁盘满了再去清理。3.2 先做一个不带 RAG 的问答链路第一步我建议先做最简单的问答链路用户输入问题模型返回答案。这一步不是为了炫技而是为了确认环境、依赖和模型调用都正常。很多新手一上来就做 RAG结果报错之后根本分不清是模型问题还是检索问题。一个最小示例的代码结构通常长这样from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI prompt ChatPromptTemplate.from_template(你是企业内部的客服助手请简洁回答问题{question}) llm ChatOpenAI(modelgpt-4o-mini) chain prompt | llm answer chain.invoke({question: 请问年假怎么申请}) print(answer)注意这里用了 LangChain 新版常见写法但实际包名和版本可能不同。如果导入报错先检查 LangChain 版本和依赖别急着改代码。跑通之后验证三件事输入输出是否正常、连续调用是否稳定、模型是否能准确理解你写的 prompt。3.3 给链路加 RAG问答链路稳定后再加 RAG。我建议先拿一小批文档做测试比如 10 到 20 篇业务 FAQ验证整个链路能通。RAG 代码的常见结构如下from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma loader TextLoader(faq.txt) documents loader.load() splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap100) chunks splitter.split_documents(documents) embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(chunks, embeddings) retriever vectorstore.as_retriever(search_kwargs{k: 4})然后把检索器和问答链拼起来from langchain.chains import RetrievalQA qa RetrievalQA.from_chain_type( llmllm, retrieverretriever, return_source_documentsTrue ) result qa.invoke(年假怎么申请) print(result[result]) print(result[source_documents])这里最关键的不是代码而是判断召回质量。你要去看检索出来的结果是不是用户真正需要的内容。如果召回结果不对先检查切片大小、重叠长度和文档清洗方式不要急着换向量数据库。3.4 把 Skills 加进来RAG 能让模型回答知识库问题但很多业务场景不只是“问答”还要执行动作。比如查订单状态、创建工单、发送审批。这时候就要给 Agent 加 Skills。Skills 的写法各家平台不完全一样但核心结构通常包含名称、描述、参数和逻辑。一个示意配置长这样{ name: query_order, description: 根据订单号查询订单当前状态和物流信息。只在用户询问订单状态时使用。, parameters: { order_id: { type: string, description: 订单号通常为字母或数字组合, required: true } } }写好的 Skills 要注册进 Agent再测试“模型是否能正确触发”。测试时我会故意用不同的说法问同一个问题比如“我的订单到哪了”“帮我看看 12345 这个单子”观察模型是否能调用同一个 Skill。如果触发不准确问题大概率在 description 写得太宽泛或太具体。要训练模型按规则触发本质是让描述和真实业务场景贴合。3.5 把 Harness 用起来当你有多个工具、多个 Skills 之后就需要 Harness 来管理执行过程。Harness 解决的是“模型乱调工具工具没返回消息后怎么处理”这类问题。实际使用 Harness 后你会看到更清晰的执行日志用户问题是什么。模型决定调用哪个工具。工具返回了什么。模型如何基于返回继续生成。最终答案是什么。我建议在切换 Harness 后先用已有的 RAG 和 Skills 案例完整跑一遍重点看日志是否完整、参数校验是否生效、失败时能不能回退。这些能力在 Demo 阶段不一定需要但到了企业级应用里没有日志和回退机制线上问题会非常难查。4. 从 Demo 到企业级FDE 的工程化框架很多人把 RAG 和 Agent 的 Demo 做出来之后下一步就不知道怎么办了。实际上从 Demo 到企业级落地并不是把代码搬到服务器上那么简单而是要把稳定性、权限、监控、失败重试这些工程问题一起补上。4.1 系统架构怎么分层企业级 AI 应用不适合把所有逻辑写在同一个脚本里。常见分层方式是客户端层网页、企业微信、钉钉、APP。接入层统一 API 网关负责鉴权、限流、日志。Agent 服务层接收用户请求解析意图调用模型和工具。知识库层向量数据库、文档索引、内容审核。模型层大模型 API 或本地模型服务。工具层订单系统、CRM、ERP、邮件系统等真实业务接口。FDE 要负责的是服务层到工具层这一段而不是只写一个模型调用函数。每一层的边界要清晰尤其是工具层不能把数据库账号直接暴露给模型调用。真实企业环境里工具调用都要经过权限校验和审计。4.2 接口设计与任务队列如果你的应用只是单用户测试同步调用没问题。但企业级应用通常需要支持多用户并发这时候就要考虑同步还是异步。同步接口适合耗时短、结果即时返回的场景比如普通问答。异步接口适合耗时长、流程多的场景比如批量文档总结、多轮 Agent 审批。异步任务一般需要一个任务队列把请求先接住再慢慢执行。任务状态要包括排队中、执行中、成功、失败、超时。用户可以通过任务 ID 查询结果。这里最容易踩的坑是“任务丢失”。如果没有持久化队列服务重启后排队中的任务会全部丢光。最开始可以简单用关系数据库存任务状态后续再换成更专业的消息队列。4.3 稳定性与可观测性AI 应用的稳定性问题比传统应用更棘手因为模型输出本身有随机性。同一个问题可能这次回答好下次回答差。所以必须靠日志和指标持续观察。建议至少记录以下内容用户请求内容。最终返回内容。模型调用耗时和 token 消耗。工具调用次数和每次结果。prompt 命中哪个版本。RAG 检索了哪些片段。是否有重试、是否有人工兜底。除了日志还要有链路追踪。因为一个请求可能经过模型、向量库、工具服务多个环节没有 trace 根本定位不了问题。好在很多 LangChain 和 Harness 工具已经提供了中间状态输出落地时把它们接入日志系统就行。4.4 安全与权限企业级 AI 应用的安全路径要提前想好不能等上线后再补。重点关注几类问题工具调用权限哪些工具允许模型自动执行哪些必须人工确认。数据访问权限不同用户能访问哪些知识库不能把 A 部门的资料召回给 B 部门。数据脱敏日志里不要记录手机号、身份证号、账号密码。输出审计模型生成了什么内容谁在什么时间看到了什么都需要留痕。FDE 在安全上的角色不是去实现安全算法而是把权限规则嵌入到 Agent 流程里。比如模型要查询客户信息前先经过一个权限判断节点不满足条件就直接拒绝不把底层数据暴露给模型。5. 用指标和验收清单判断结果好不好企业级 AI 应用不能只说“效果不错”要能定义指标、能验证、能回归。不同场景需要不同指标下面几个是 FDE 实际项目里用得比较多的。5.1 RAG 知识库指标怎么理解很多人做 RAG 只关心“看起来答得对不对”但上线前必须量化。常见指标有指标含义实际解读召回率应该召回的相关文档是否被召回了低说明切片、embedding、检索策略有问题精确率召回的文档里真正相关的比例低说明无关内容太多需要调重排序或降 kMRR第一个正确答案排在结果列表中的位置反映排序质量越高越好引用准确率答案引用的知识片段和业务文档是否一致防止模型自己编造引用上线前必查这些指标不是调一次就结束。业务文档更新后指标可能下降。所以最好建立一套测试集每次改动都跑一遍回归。5.2 Agent 技能成功率Skills 不能只看“能不能调用”还要看“调用后任务是否成功”。我一般分三个粒度看触发准确率该触发时触发不该触发时不触发。参数完整率参数是否齐全、类型是否正确。流程完成率调用工具后是否能完成后续生成或步骤。这三个指标会互相影响。参数不完整流程完成率一定低。流程完成率低可能是模型对工具返回值理解不够也可能是提示词里没有说清楚下一步规则。5.3 生产环境性能指标上线后还要关注P95 延迟大多数请求的耗时要稳定不能忽快忽慢。并发上限多少用户同时使用时服务开始不可用。Token 消耗单个请求平均消耗多少批量增长后成本是否可控。失败率包括接口报错、超时、模型服务不可用。这些指标决定了你后期是调流程还是先扩资源。很多项目效果不错但上线后没人用就是因为延迟太高或成本太高。5.4 验收清单每一项新功能上线前我都会过一遍清单正常路径是否走通。用户换一种说法是否还能触发正确流程。超出边界时是否优雅拒绝。工具服务不可用时是否有兜底回答。日志是否完整能否定位问题。权限是否控制正确。召回结果是否带可溯源标识。这个清单不用一次到位但至少要覆盖正常、异常、边界三类情况。AI 应用最怕的就是只测正常路径上线后被一个无厘头问题打崩。6. FDE 实战常见问题和排查链路FDE 的工作里排查问题占很大比例。下面几个问题我几乎每个项目都会遇到给出通用排查顺序。6.1 模型输出乱跑工具参数不对先看模型是否真的理解了工具描述。排查顺序查看模型调用日志确认模型有没有选择正确工具。如果选择了正确工具再看参数是否有缺漏。如果参数不对通常要改 Skills 里的参数描述把必填字段和格式写得更明确。如果模型频繁调用错误工具检查工具 description 是否和其他工具重叠。不要一上来就换大模型。大部分参数不对问题是描述不清而不是模型不够聪明。6.2 RAG 召回一堆无关内容这是 RAG 最常见问题。排查链路先检查测试问题本身是不是包含太多无意义词汇。看检索出来最靠前的几个片段的相似度分数如果很低说明向量化效果不好。检查文档切片是否完整有没有把一句话拆成两半。检查 embedding 模型是否和业务语言匹配英文模型处理中文效果可能不稳定。如果基础检索没问题但最终答案差可以考虑加一层重排序在召回后精排。6.3 Agent 循环调用工具停不下来Agent 出现死循环通常是工具返回的结果没有让模型获得“足够的新信息”。排查顺序看原始问题是什么。看每次工具调用返回了什么。如果工具返回内容太复杂或太简单模型可能判断不了下一步。设置最大迭代次数不能无限循环。在提示词里补充明确的终止规则比如“当用户不需要更多操作时直接给出总结”。6.4 本地 Harness 起不来或系统差异Harness 这类工具迭代很快系统差异和依赖冲突很常见。排查顺序确认 Python 版本是否在要求范围内。确认是否缺少系统级依赖比如某些库在 Linux 上需要额外编译。查看启动日志最后几行通常真正报错原因在最下面。翻一下工具的 release notes看最新版本是否有问题。实在不行就降级到上一个稳定版本不要一直在 main 分支上挣扎。6.5 依赖版本冲突和模型兼容LangChain 生态里依赖冲突几乎是每天都要面对的事。一个常见场景是 LangChain 核心包和第三方向量库版本不匹配导致某个类突然导入不了。我的排查顺序是记录当前环境的依赖版本列表。看报错指向哪个包优先去对应项目的变更日志。不要一次性升级所有依赖先固定核心包版本。如果项目不是特别复杂可以直接建一个干净虚拟环境重新装依赖装完再逐步加包。模型兼容问题也很常见。有些提示词格式只适合特定模型换一个模型后输出就变了。所以生产环境一定要固定模型版本至少固定模型名称和参数不能“默认最新版”。7. 想转 FDE 的工程师我建议先做这几件事这个方向听起来很宽但入门和进阶其实有明确路径。我给几个比较实际的建议。7.1 找到一个能天天摸到真实反馈的场景FDE 需要极强的业务感知能力。如果你只是自己在测试环境里跑 LangChain很难知道真实用户会怎么提问。建议找一个真实场景比如给团队内部做一个文档问答工具或者给某个业务部门做一个自动化工单助手。哪怕很小只要有人用你就能拿到真实反馈。用户问的问题会五花八门“这个文件为什么显示乱码”“为什么周报没有统计上周数据”。这些问题听起来不像 AI 问题但恰恰是 FDE 要解决的核心问题。真实反馈比任何教程都更能逼你成长。7.2 不要同时学十个框架先吃透一条链路LangChain、LangGraph、各种 Harness、不同向量库新手很容易东看一个西学一个最后什么都没深入。我更建议先固定一条链路LangChain 一个向量库 一个模型 API 一个 Harness把从文档导入到 RAG 检索再到 Skills 调用的完整流程跑通。然后再考虑要不要换 LangGraph要不要换更专业的 Harness。技术选型不是第一步先确认自己能把问题解决才有资格谈选型。7.3 把每次排查沉淀成 Skills 或模板FDE 的成长不是靠背教程而是靠积累排查经验。每次解决一个问题都可以想想能不能沉淀成一种固定处理方式。比如“遇到长文档检索不准先做数据清洗再调参数”这本身就是一个 Practice。写 Skills 也是这样。团队里经常有人问同样的问题你就可以把这个问题的回答逻辑写成一个 Skill。下次用户再问Agent 能自动处理。FDE 的长期价值就是不断把重复工作固化成自动化能力。7.4 保持对业务结果敏感最后一点FDE 不是只写代码的人。你要关注这个 AI 应用上线后是不是真的帮用户省了时间。如果 RAG 工具有人用但没人信任说明引用准确率不够如果 Agent 工具调用频繁失败说明流程设计有问题。我习惯每个迭代都问自己一句这个功能上线后业务方会怎么评价如果答案是“没什么感觉”那就说明需求没抓准。技术指标再好业务反馈差项目依然会失败。踩过几次坑之后我发现FDE 真正难的不是学会某个模型或框架而是能在复杂业务里保持判断力哪些问题值得自动化哪些问题必须人工处理哪些数据要先清洗哪些流程要先简化。技术工具会不断换但这条判断力才是长期积累的核心竞争力。