最近业界开始频繁出现 FDEForward-Deployed Engineer这个称呼。很多刚从 LLM 入门转向业务落地的开发者第一反应是这不就是“部署工程师”换了个名字吗实际了解之后会发现它描述的是一类更特殊的角色——既要懂模型怎么调又要懂业务怎么拆还得能把 Agent、RAG、工具链这些东西组合成一套真正可运行、可维护、可评估的系统。这篇文章想聊清楚的事情只有一件AI 应用从 Demo 到生产中间那一大段没人明确负责的“胶水层”到底该怎么做。我会从 FDE 的能力模型讲起拆开 LangChain、Harness、Skills、RAG 四个核心关键词然后用一个可运行的知识库问答项目把从检索增强到 Agent 工具调用、再到工程化部署的完整链路走一遍。读完你至少能判断自己的项目卡在哪一层以及下一步该补什么。1. 先搞清楚FDE 到底在解决什么问题FDE 的全称是 Forward-Deployed Engineer直译是“前沿部署工程师”。这个词最早更多出现在 ToB 软件公司和云厂商的实施团队里但 AI 时代它被重新赋予了内涵当一个企业要接入大模型能力时真正困难的不是拿到一个聪明的模型而是把模型嵌进原有的业务流程、数据结构和决策链路里。过去做软件交付流程通常是“产品提需求、后端写接口、前端做页面、实施去部署”。但在 AI 应用场景里这套分工失效了。原因在于大模型的行为并非完全确定它需要检索什么样的知识、调用什么工具、在什么条件下给出结论这些工作很难提前用静态需求文档描述完整。于是需要一个更接近业务的工程师一头扎进客户现场快速理解业务痛点再基于模型能力设计方案并直接落地。FDE 工程师的核心工作可以拆成四块理解业务场景判断哪一部分真正适合 AI 解决。设计 Agent 的工作流程决定模型什么时候该检索、该调用工具。编写和管理 Skills也就是把企业已有的 API、数据库、规则脚本包装成模型能够调用的能力。搭建 RAG 知识库让模型掌握企业内部的事实而不是只依赖训练时的通用知识。这四块能力组成了一条完整的 AI 应用落地链路。传统工程师往往只覆盖其中一块而 FDE 的价值在于能同时覆盖整条链路。关键点在于FDE 不是“更懂算法的提示词工程师”也不是“更懂业务的算法工程师”。它更像是一个懂模型特性的全栈集成者——知道模型哪里强、哪里弱知道怎么用工具补足模型的短板知道如何设计评估方式让老板和客户确信系统真的可用。2. 核心技术栈全景LangChain、Harness、Skills、RAG 的关系很多新手一上来就被这四个词搞混了。其实它们处于不同的抽象层次彼此之间是组合关系不是竞争关系。RAGRetrieval-Augmented Generation检索增强生成解决的是“模型不知道企业知识”的问题。企业内部的制度手册、技术文档、售后记录都在本地库里模型没有见过。RAG 的做法是先把文档切块、向量化、存入向量数据库用户提问时先检索最相关的片段再把片段拼进提示词让模型生成答案。这套机制目前是 AI 落地最成熟、最高性价比的方案。LangChain 是一个 Agent 编排框架。它提供了一套标准接口把大模型、向量库、工具、记忆、提示词模板都串起来。注意 LangChain 不是模型也不是向量库它更像是“乐高底座”。需要特别区分的是 LangGraph——它是 LangChain 团队推出的下一代编排框架最大的变化是支持把流程定义成有状态、可分支的图结构适合复杂的多步骤 Agent 流程。简单场景用 LangChain 就够复杂流程则更适合 LangGraph。Harness 在 AI 工程里的含义可以理解成“控制 Agent 运行的骨架和缰绳”。它把模型配置、Skill 列表、记忆存储、日志观测集中在一个可控的运行环境里。开发者在 harness 里声明好模型参数、给 Agent 挂上哪些技能、记录哪些 trace然后 Agent 才能以可预期、可回溯的方式工作。在热词里你能看到 DeepSeek Harness、Codex Harness 这些产品它们本质上都是同一件事让 Agent 从“临时脚本”变成“工程系统”。Skills技能是 Agent 的“能力单元”。模型本身不会算请假天数、不会查库存、不会调用公司的审批流但这些都可以通过 Skills 暴露给模型。一个 Skill 就是一个可以被模型按名称和描述调用的功能接口底层可以是一段 Python 函数、一个外部 API、一条 SQL 查询或另一个 RAG 流程。Skills 设计得越好Agent 的稳定性和业务边界就越清晰。四者之间的关系可以这样理解RAG 解决了“知识从哪里来”。Skills 解决了“能力从哪里来”。LangChain/LangGraph 解决了“流程怎么编排”。Harness 解决了“运行环境怎么管理和观察”。判断这四个技术组合在一起构成了 FDE 落地 AI 应用的完整工具箱。只掌握其中任意一个都很难独立交付一套企业级 AI 应用。3. 环境准备与前置条件本文后面的实战代码基于 Python 生态建议使用 Python 3.10 或更高版本。核心依赖如下langchain langchain-community langchain-openai faiss-cpu pypdf fastapi uvicorn安装命令mkdir fde-demo cd fde-demo python -m venv .venv source .venv/bin/activate pip install langchain langchain-openai langchain-community faiss-cpu pypdf fastapi uvicorn模型方面你可以使用 OpenAI 兼容接口的服务也可以使用国内支持 OpenAI 协议的大模型服务。后文代码里统一通过环境变量控制 API Key 和 Base URL不写死某个厂商。export OPENAI_API_KEYsk-your-key-here # 如果使用兼容 OpenAI SDK 的国产模型服务可以配置 base_url export OPENAI_BASE_URLhttps://your-model-provider/v1这里不需要指定具体版本号因为 LangChain 的 API 演进较快。实际项目中建议先锁定一个大版本再固定依赖避免小版本升级导致接口不兼容。4. RAG 实战从零构建一个企业知识库问答应用先做一个最小可用的 RAG 应用。场景假设企业有一本员工手册 PDF 和若干政策文档需要让员工通过自然语言提问AI 基于这些文件回答而不是靠模型凭空编造。4.1 文档加载与切分# file: rag_build.py import os from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import FAISS # 1. 加载 PDF 文档 loader PyPDFLoader(employee_handbook.pdf) documents loader.load() # 2. 文本切分按语义块切分保留重叠上下文 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , ., , ] ) chunks splitter.split_documents(documents) print(f切分后共 {len(chunks)} 个片段) # 3. 向量化并写入本地向量库 embeddings OpenAIEmbeddings() vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(faiss_index) print(向量库构建完成)切分参数很重要。chunk_size 太大检索粒度粗容易把不相关内容混进来太小又可能导致单个片段缺乏完整上下文。chunk_overlap 的作用是保留片段之间的衔接信息避免一个句子被拦腰截断。4.2 检索问答# file: rag_query.py import os from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import FAISS from langchain.chains import RetrievalQA # 加载向量库 embeddings OpenAIEmbeddings() vectorstore FAISS.load_local( faiss_index, embeddings, allow_dangerous_deserializationTrue # 仅在信任该向量库文件时开启 ) # 构造检索器每次取最相关的 3 个片段 retriever vectorstore.as_retriever(search_kwargs{k: 3}) # 构造模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0.1) # 构造问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverretriever, return_source_documentsTrue ) # 提问 question 员工每年有多少天带薪年假 result qa_chain.invoke({query: question}) print(回答:, result[result]) print(依据片段:) for doc in result[source_documents]: print(---) print(doc.page_content[:100])这里有两个设计要点一是“stuff”链类型会把检索到的所有片段拼进一次提示词适合片段较少、上下文不超长的场景。如果知识库片段很多后续可以切换为 map_reduce 或 refine 策略。二是 return_source_documentsTrue 非常关键。企业级应用不能只给结论要能追溯到回答来自哪份文档的哪个片段否则无法审查和追责。4.3 运行与验证python rag_build.py python rag_query.py运行成功后应该能看到“回答”和“依据片段”两部分输出。如果看不到依据片段说明代码里 return_source_documents 参数没有生效先检查这一项。判断RAG 的最佳实践是先让系统“有据可查”再谈“回答准确”。没有来源引用的 RAG和直接问大模型没有本质区别。5. 从 RAG 到 Agent用 LangChain 实现多技能协作RAG 解决了知识问题但只做问答还不够。实际业务中用户提问往往需要多个步骤协作。比如“我在公司工作 6 年今年可以休几天年假”这个问题里模型既要查政策还要根据工龄做计算。只有 RAG 的话模型很可能只从文档里找到一段政策截断然后自己瞎算。这时候需要引入 Agent 和 Skills。5.1 定义 SkillsSkill 本质上就是一个带描述的函数。LangChain 通过 Tool 抽象来管理它模型根据用户问题和工具描述决定要不要调用这个 Skill。# file: skills/hr_skills.py def calculate_annual_leave(years: int) - str: 根据司龄计算年假天数。司龄小于5年5天5到10年10天10年以上15天。 if years 10: return 15天 if years 5: return 10天 return 5天 def query_hr_policy(question: str) - str: 查询 HR 政策知识库返回与问题相关的政策原文摘要。 # 生产环境这里应该调用上一节的 RAG 接口 return 根据员工手册年假申请需提前3个工作日提交审批通过后方可休假。Skill 的 description 要写得足够清楚因为模型是靠描述来决定什么时候调用。描述含糊模型就会在错误的时机调用或者在需要的时候不调用。5.2 构建 Agent# file: agent_app.py from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain_core.tools import Tool from langchain_core.prompts import ChatPromptTemplate from skills.hr_skills import calculate_annual_leave, query_hr_policy tools [ Tool(nameannual_leave_calculator, funccalculate_annual_leave, description根据司龄计算年假天数), Tool(namehr_policy_qa, funcquery_hr_policy, description查询公司 HR 政策知识库), ] llm ChatOpenAI(modelgpt-4o-mini, temperature0) prompt ChatPromptTemplate.from_messages([ (system, 你是企业 HR 智能助手。回答问题时必须基于已有工具的结果不要编造政策。), (user, {input}), (assistant, {agent_scratchpad}), ]) agent create_react_agent(llmllm, toolstools, promptprompt) executor AgentExecutor( agentagent, toolstools, max_iterations3, verboseTrue, ) result executor.invoke({input: 我在公司工作6年今年有多少天年假}) print(最终回答:, result[output])运行命令python agent_app.py打开 verbose 后可以看到模型在思考要不要调用工具、调用哪一个、拿到结果后如何组织答案。这里最典型的错误是工具函数抛异常时模型不知道怎么办或者模型在一个工具没返回时就强行给结论。max_iterations 是重要保护参数防止模型陷入无限循环。6. Harness 工程化从脚本到可维护的 AI 应用演示项目跑通后下一步是把零散脚本组织成可维护的系统。Harness 在这个阶段发挥价值。它通常承担四个职责集中管理模型配置和运行参数。声明当前 Agent 挂载哪些 Skills。配置记忆存储、向量库位置。记录日志、调用链和评估数据。一个典型的 Harness 配置可以长这样# file: fde-harness.yaml version: 1.0 model: provider: openai-compatible base_url: ${OPENAI_BASE_URL} api_key: ${OPENAI_API_KEY} name: gpt-4o-mini temperature: 0.1 max_tokens: 2048 skills: - name: annual_leave_calculator type: python_function entry: skills/hr_skills.py description: 根据司龄计算年假天数 - name: hr_policy_qa type: rag_channel vectorstore: ./faiss_index top_k: 3 description: 查询公司 HR 政策知识库 memory: type: sqlite path: ./memory.db observability: log_level: INFO trace: true这份配置的价值在于把“改模型”“换技能”“调知识库”从改代码变成了改配置。上线新技能时不需要改动 Agent 主体逻辑只需要在 harness 配置里追加一个 Skill然后重新加载服务即可。在生产项目中Harness 配置应当纳入版本管理跟随业务迭代一起评审和发布。配置变更要有审计记录避免出现“开发环境能跑、生产环境不工作”的配置漂移问题。7. API 服务化与生产环境注意点Agent 不能只活在命令行里要接入企业应用就需要提供 HTTP 接口。用 FastAPI 封装是最直接的方式。# file: api_server.py from fastapi import FastAPI from pydantic import BaseModel from agent_app import executor app FastAPI(titleHR Agent Service) class QueryRequest(BaseModel): input: str session_id: str default class QueryResponse(BaseModel): output: str app.post(/agent/query, response_modelQueryResponse) def agent_query(req: QueryRequest): # 生产环境应加上鉴权和限流 result executor.invoke({input: req.input}) return QueryResponse(outputresult[output]) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)启动命令uvicorn api_server:app --host 0.0.0.0 --port 8000服务上线时有几个关键点必须确认接口鉴权不能让未授权用户随意调用 Agent。敏感信息脱敏日志里不能出现员工 ID、薪资数据。超时和重试大模型接口可能慢或偶发失败需要设置合理的超时时间。并发控制Agent 调用是 CPU 和 IO 密集操作生产环境需要用消息队列或异步任务处理高并发请求。模型版本固化线上和测试环境必须使用同一模型版本否则回答质量会出现不可控差异。判断企业级 AI 应用的第一原则是“可控”第二原则是“可观测”。一个能跑但无法解释、无法回滚、无法评估的 Agent不具备生产价值。8. 常见问题与排查思路问题现象可能原因排查方式解决方案检索结果不相关文档切分粒度不合适Embedding 模型与领域术语不匹配打印召回片段检查 chunk_size 和 top_k调整切分参数换更强的 Embedding 或做领域微调回答出现幻觉知识库没提到也能编提示词未约束召回片段不足检查 return_source_documents 是否开启对比依据片段和最终回答在提示词中明确“只能根据给定资料回答”加大 top_k加入答案校验Agent 不调用工具或调用错误工具Skill 的 name 或 description 不清晰模型版本能力不足打开 verbose 观察模型思考过程重写 Skill 描述换更强模型简化工具数量调用国产模型时报错base_url 或模型名配置错误接口协议不完全兼容查看接口返回报文确认使用 OpenAI 兼容协议的真实 base_url用官方 SDK 自测服务并发一高就超时向量检索和模型调用都是阻塞操作查 CPU、IO、模型接口耗时异步化处理增加缓存把模型推理拆到独立服务本地正常生产环境回答不一致环境变量、依赖版本、模型参数不同对比配置和依赖锁定文件用配置中心统一管理参数锁定全部依赖版本排查顺序有一条通用路径先看输入提示词再看检索召回片段最后看模型输出。三者分别对应“问题问得对不对”“资料找得准不准”“答案生成得好不好”。大多数 RAG 和 Agent 事故都能在召回环节找到原因。9. 企业级 AI 应用落地的最佳实践结合 FDE 的工作方式总结几条经得起生产检验的经验。第一先做 RAG再上 Agent。不要一开始就设计复杂的多工具协作流程。先把一个知识库问答场景做扎实让大家敢用、愿用再逐步叠加工具调用和自动化操作。第二Skills 要当成内部 API 来设计。每个 Skill 要有清晰的名字、入参、出参和错误处理。模型是靠描述来理解 Skill 的描述写得像需求文档模型就不容易“理解偏差”。Skill 内部实现细节要隔离避免模型直接操作底层数据库。第三Harness 配置走版本管理。模型的温度、top_p、Skill 列表、知识库路径都是配置项不是代码里的魔法值。配置变更要和业务需求关联做到“哪个版本回答了什么问题”都能回溯。第四评估指标要围绕业务来定。除了技术指标如召回率、准确率、幻觉率还要关注业务指标用户问题是否被正确路由、回答是否为用户解决了实际问题、一次对话中需要多少次人工介入。这些指标必须提前定义否则团队会对“新版到底有没有变好”争论不休。第五安全边界要提前划清。Agent 能调用的权限永远小于等于普通员工的权限。涉及删除、修改、转账等高风险操作必须设计人工确认环节。知识库文档要做权限分级不能让所有用户检索到所有内部信息。第六小步快跑灰度验证。先在 10 个内部用户中试用收集问答质量和失败案例用真实数据迭代一轮后再扩大范围。AI 应用的稳定性不是上线那一刻验证出来的而是通过持续的小范围试运行磨出来的。10. 总结与后续学习方向FDE 不是一个虚幻的岗位名称它代表着一套 AI 落地方法论理解业务边界用 RAG 补充模型知识用 Skills 扩展模型能力用 LangChain/LangGraph 编排流程用 Harness 保证可控运行最后用工程手段完成部署、观测和迭代。如果你现在刚接触这个方向建议按这个路径推进先搭一个完整的 RAG 应用跑通文档加载、切分、向量化、检索、生成全流程重点理解“召回”和“排序”对最终答案的影响。在此基础上引入 Agent把一个 Skill 接入流程感受模型如何通过工具调用解决“计算”和“查证”问题。学习 LangGraph把多个步骤组织成有状态的工作流处理分支、循环和异常跳转。把应用封装成服务加上日志、追溯、权限和评估思考“如果我是运维这个系统能不能出问题自愈、出现问题可排查”。回到业务场景里找一个真实的高频问题持续迭代到业务方愿意每天使用。AI 应用开发的门槛正在从“会不会调模型”转向“会不会把一个业务问题拆解成可运行的 AI 系统”。FDE 的核心竞争力不是写多复杂的 Prompt而是具备把模型、工具、数据和业务流程焊在一起的能力。后续值得深入的方向包括 Agentic RAG让 Agent 自主决定检索策略、Ontology RAG用知识图谱约束检索范围、以及更成熟的 Harness 工具链。每踩一个坑都是理解这套方法论边界的机会。