1. 从能调工具到能干活之间隔了什么很多人第一次把 Agent 跑通工具调用的时候都会经历一个短暂的兴奋期模型能读文件了、能查数据库了、能发请求了感觉离AI 自动干活就差临门一脚。但真把它丢进一个稍微正经点的业务场景里你会发现它立刻变得笨拙——查出来的数据是错的、该看的表没权限、流程走到一半卡在审批节点上、写回去的字段格式对不上。问题不在于模型不够聪明而在于我们只给了它手没给它身份地图和规矩。这篇要聊的就是这个断层。标题里提到的 FDE我把它理解成一种角色定位——Forward Deployed Engineer也就是那种被派到业务一线、既懂技术又懂现场的人。他们的核心工作不是训练模型而是把 AI 真正接进数据、权限和真实流程里。工具调用只是最表层的一环真正决定 Agent 能不能落地的是它背后那套接入工程。我见过太多 Demo 惊艳、上线即废的项目根子都在这。如果你正在做 Agent 相关的落地或者你本身就是那个被派到业务现场的人这篇内容应该能帮你少走几个月的弯路。我会从数据接入、权限设计、流程编排、状态管理这几个维度把接进去这件事拆开讲每个环节都给出我实际踩过的坑和验证过的做法。不聊虚的只讲能抄作业的部分。2. 数据接入Agent 拿到的数据为什么总是看起来对用起来错2.1 直接连库是最容易踩的坑新手最容易犯的错就是给 Agent 一个数据库连接串让它自己写 SQL 查。跑 Demo 的时候很爽因为数据干净、表结构简单、问题也简单。但真实业务库里是什么情况字段命名混乱、同一含义分散在三四张表、历史数据有大量脏值、枚举值没有文档、时间字段有的是时间戳有的是字符串。Agent 生成的 SQL 语法上没问题语义上全是坑。我的做法是永远不要让 Agent 直接面对原始库。中间必须加一层语义层把业务概念映射到物理表。比如业务上说活跃客户背后可能是三张表的 join 加一堆过滤条件这层逻辑应该固化在语义层里Agent 只需要说给我活跃客户列表就行。这层可以用视图、可以用专门的查询服务、也可以用配置化的指标平台形式不重要重要的是把业务语义和物理存储解耦。提示语义层不是给 Agent 看的是给你自己维护的。Agent 看到的应该是稳定的业务接口底层表怎么变都不影响它。2.2 数据新鲜度和一致性要显式声明Agent 有个很隐蔽的问题它不知道自己拿到的数据是什么时候的。你问它现在库存多少它查出来一个数就答了但这个数可能是十分钟前缓存的也可能是昨天批量同步的。在真实业务里这个时间差可能就是事故。我的处理方式是在数据接口的返回里强制带上元信息数据时间戳、来源系统、更新频率、是否实时。Agent 在回答时如果涉及时效敏感的问题必须把这些信息一并呈现。比如根据 15 分钟前同步的库存快照当前可用量为 X。这看起来啰嗦但能避免大量AI 胡说的投诉——很多时候不是它算错了是它没说清楚数据的时间边界。另外一致性也要考虑。跨系统查询时A 系统的订单和 B 系统的库存可能对不上因为同步有延迟。这时候 Agent 如果直接做减法结果就是错的。我的经验是跨源数据不要在 Agent 层做实时聚合要么在数据层预先做好一致性视图要么在 Agent 回答时明确标注该结果基于不同时间点的数据可能存在偏差。2.3 结构化与非结构化数据的混合检索真实场景里Agent 要处理的不只是表格。合同是 PDF、沟通记录是文本、工单描述是自由格式、附件可能是图片。这些非结构化数据和结构化数据要能一起被检索和引用。我常用的方案是统一检索层结构化数据走查询接口非结构化数据走向量检索然后在 Agent 侧做结果融合。但这里有个细节很多人忽略——引用要可追溯。Agent 说根据合同第三条你得能点回去看到原文。所以非结构化数据的检索结果必须带原文定位信息页码、段落、甚至字符偏移。没有这个业务方根本不敢信。还有个实操心得非结构化数据的切分粒度很关键。切太碎检索出来的片段没有上下文Agent 理解不了切太粗检索精度下降噪音多。我的经验是按语义单元切比如合同按条款、工单按处理记录、邮件按往来轮次。切完之后给每个片段加上来源、时间、涉及主体这些元数据检索时可以用元数据做过滤效果会好很多。3. 权限设计Agent 不能是超级用户也不能是透明人3.1 权限要跟着谁在问走而不是Agent 是谁最常见的错误设计是给 Agent 一个固定的高权限账号让它能访问所有数据。这在 Demo 阶段很方便上线就是灾难。因为 Agent 本身没有身份它代表的是发起请求的那个人。如果张三只能看自己部门的销售数据那 Agent 替张三查的时候就不能看到李四部门的。正确的做法是权限透传用户发起请求时带上身份凭证Agent 在调用每个数据接口时都用这个身份去鉴权。这意味着 Agent 本身不持有权限它只是一个代问的角色。实现上可以在请求上下文里传递用户 token每个下游服务自己校验。这样即使 Agent 被诱导去查不该查的数据下游也会拒绝。注意权限透传要求整条链路都支持用户级鉴权。如果某个数据源只支持服务级账号那就要在这层做额外的过滤确保返回的数据范围不超过用户权限。3.2 工具级权限和数据级权限要分开管Agent 能调用的工具本身也需要权限控制。不是每个用户都能触发删除订单这种操作哪怕 Agent 有这个工具。我的做法是两层控制第一层是工具可见性用户没权限的工具根本不暴露给 Agent第二层是数据范围工具能调但只能操作权限内的数据。举个例子一个修改客户备注的工具所有客服都能用但只能改自己负责的客户。工具可见性上它对所有客服开放但执行时要在数据层校验这个客户是不是当前客服负责的。这两层缺一不可。只做工具级控制会出现越权改数据只做数据级控制会出现不该出现的工具被调用。3.3 敏感操作的二次确认与审计有些操作即使权限允许也不应该让 Agent 直接执行。比如退款、删除、对外发送。这类操作我建议加一道确认机制Agent 生成操作意图展示给用户确认用户点了才真正执行。这不是不信任 AI而是给业务方一个心理安全垫。同时所有 Agent 发起的操作都要有审计日志记录谁、什么时候、通过什么工具、操作了什么数据、结果如何。这个日志不只是合规需要排查问题时极其有用。我遇到过 Agent 批量修改数据导致异常的情况全靠审计日志定位到具体是哪次调用、传了什么参数。审计日志的字段设计我建议至少包含请求 ID、用户标识、会话 ID、工具名称、入参摘要、出参摘要、执行时间、耗时、是否成功、错误信息。入参出参不要存全量存摘要或哈希就行避免日志本身成为数据泄露点。4. 流程编排Agent 不是孤岛要嵌进现有业务流4.1 先搞清楚流程的卡点在哪很多团队一上来就想让 Agent 端到端跑完整个流程结果发现处处是坑。我的建议是先做流程梳理找出哪些环节是人做起来烦但规则明确的这些才是 Agent 最适合切入的点。比如信息录入、初步分类、资料检索、标准回复生成这些环节规则清晰、容错空间大Agent 做起来收益明显。反过来涉及判断、协商、例外处理的环节短期内还是人来做更稳。Agent 可以在旁边做辅助比如提供参考信息、起草方案但决策权留给人。这种人机分工的设计比追求全自动要务实得多。4.2 状态管理是流程编排的命门Agent 在多轮交互里最容易丢状态。用户第一轮说了订单号第三轮问这个能退吗Agent 如果记不住订单号整个对话就废了。更麻烦的是跨系统的状态Agent 在 A 系统创建了工单在 B 系统查了物流这两个状态要能关联起来。我的做法是引入一个会话状态存储把关键实体和上下文显式存下来。不要指望模型自己记住上下文窗口再大也不可靠。状态存储里放什么用户身份、当前任务、已确认的实体订单号、客户 ID 等、已执行的操作、待确认的事项。每次 Agent 调用前把相关状态注入调用后更新状态。这里有个细节状态要有过期和清理机制。不然会话越积越多存储爆炸而且旧状态可能污染新会话。我一般设置会话级别的 TTL比如 24 小时不活跃就清理同时关键业务状态落到业务系统里不依赖会话存储。4.3 异常分支和回退路径要提前设计正常流程跑通不难难的是异常。数据查不到怎么办权限被拒怎么办下游系统超时怎么办这些分支如果不提前设计Agent 就会卡住或者给出莫名其妙的回答。我的经验是给每个工具调用定义明确的失败语义是没找到还是没权限还是系统故障Agent 要根据不同情况给出不同回应。没找到就引导用户补充信息没权限就说明原因并建议走什么流程系统故障就提示稍后重试并记录。这些看起来是细节但直接决定用户体验。回退路径也很重要。Agent 执行到一半失败了已经做的操作要不要撤销这取决于业务。有些操作是幂等的重试就行有些操作有副作用需要补偿。设计流程时要把这些想清楚别等出事了再补。5. 真实流程接入中的几个硬骨头5.1 遗留系统的接口适配真实业务里总有几个上古系统接口是 SOAP 的、返回是 XML 的、认证是自定义的、文档是没有的。Agent 要接进去中间得做适配层。这层工作很脏很累但绕不过去。我的做法是把适配层做成独立的服务对外暴露统一的 REST 接口内部处理协议转换、认证、重试、超时。适配层要加详细的日志因为遗留系统出问题时你只能靠日志排查。另外要做好限流遗留系统往往很脆弱Agent 并发一高就打挂了。5.2 长流程的超时与异步处理有些业务流程很长比如审批要等几天。Agent 不能一直挂着等得支持异步。我的方案是把长流程拆成发起和查询两个阶段Agent 发起流程后拿到一个流程 ID然后可以定期查询状态或者由流程引擎在状态变更时回调通知。这里要注意的是Agent 的会话可能已经结束了但流程还在跑。所以流程状态要独立存储不能依赖会话。用户下次来问的时候Agent 能根据流程 ID 查到最新状态。5.3 多系统数据冲突的处理同一个事实在不同系统里可能不一致。客户电话在 CRM 里是一个号在工单系统里是另一个号。Agent 该信哪个我的原则是定义权威源每个字段指定一个主系统其他系统的值只做参考。Agent 回答时以权威源为准如果发现不一致可以提示检测到不同系统记录不一致以 X 系统为准。这个权威源的映射要维护成配置不能硬编码在代码里。业务变化很快今天 CRM 是权威明天可能就换成别的系统了。6. 上线之后监控、迭代与那些没人告诉你的细节6.1 监控要盯的不是成功率而是业务指标Agent 上线后技术监控当然要有调用量、延迟、错误率。但真正重要的是业务指标任务完成率、人工介入率、用户满意度、平均处理时长。我见过技术指标全绿但业务方怨声载道的项目因为 Agent 确实在响应但响应的内容没用。建议在 Agent 的每个关键节点埋点用户发起了什么意图、Agent 调了哪些工具、最终有没有解决问题、用户有没有转人工。这些数据积累起来才能知道该优化哪里。6.2 提示词和工具描述要持续迭代Agent 的表现很大程度上取决于工具描述和提示词。上线不是终点而是迭代的起点。我一般会收集Agent 用错工具和Agent 该用工具却没用的案例反过来优化工具描述。工具描述要写清楚这个工具干什么、什么时候用、参数什么意思、返回什么、有什么限制。写得越清楚Agent 用得越准。提示词也一样不要指望一版就完美。根据实际 badcase 持续调整每次改完做回归测试确保没把之前修好的问题又改回去。6.3 给业务方一个反馈按钮这个听起来很产品但极其重要。业务方用 Agent 的时候遇到不对的地方要能一键反馈。这个反馈直接进到你的迭代队列里比你自己猜哪里有问题高效得多。而且反馈本身也是数据积累多了能看出系统性问题。反馈入口要做得轻别让用户填一堆表单。一个这不对按钮加上可选的补充说明就够了。关键是让反馈的路径足够短短到用户愿意点。7. 我踩过的几个印象深刻的坑第一个坑是权限缓存。为了性能我把用户权限缓存了 5 分钟。结果用户权限被回收后Agent 还能继续访问直到缓存过期。这在审计时被揪出来了。后来改成权限变更时主动失效缓存虽然复杂点但安全。第二个坑是工具描述太模糊。有个工具叫查询信息Agent 经常在不需要的时候调它因为描述太泛了。后来改成根据订单号查询订单状态和物流信息调用准确率立刻上去了。工具命名和描述要具体别用处理管理这种大词。第三个坑是没做输入校验。Agent 传的参数格式不对下游系统直接报错但错误信息很晦涩Agent 理解不了就反复重试把下游打挂了。后来在工具层加了参数校验和友好的错误返回Agent 能根据错误信息调整参数重试成功率大幅提升。第四个坑是忽略了并发。两个用户同时让 Agent 操作同一个订单一个改地址一个改数量结果互相覆盖。后来在数据层加了乐观锁冲突时提示用户重试。Agent 场景下并发冲突比想象中常见因为 Agent 操作快用户可能同时发起多个请求。8. 关于 FDE 这个角色的一点个人体会做这类工作技术能力只是一半另一半是翻译能力——把业务的模糊需求翻译成技术方案再把技术限制翻译成业务能理解的语言。我见过技术很强但推不动项目的 FDE问题往往出在沟通上。业务方说我要 AI 帮我处理客户问题你得追问哪类问题、现在怎么处理的、痛点在哪、期望达到什么效果。问清楚了方案自然就出来了。另外要有最小可用的意识。别一上来就追求大而全先找一个痛点明确、边界清晰的场景跑通拿到业务方的信任再逐步扩展。Agent 落地是个渐进过程不是一锤子买卖。每次交付一点价值积累起来就是大价值。最后保持对数据的敬畏。Agent 再聪明数据错了结果就是错的。接入之前先花时间理解数据比急着写代码重要得多。我花在数据探查上的时间往往比写接入代码的时间还长但我觉得值。