「FDE 落地方法」系列 · 能力标尺 本篇讲四个能力维度怎么评估；人的三组素质见FDE 能力要求与招聘 ，岗位边界见FDE 与实施等岗位的区别 ，交付方法见我们怎么做 FDE 。
面试的会议室里，候选人聊起模型参数、框架选型、检索策略，条理清楚。换一道题：这家公司的合同审批流程，你打算拆成几步、哪些节点留人签字。回答开始含糊。
会调接口的人现在不缺。拉开差距的是另外四件事，它们都不写在方案目录里，上线以后才显出来。 这篇文章拆开这四件事，以及前两件和后两件各自管什么。
FDE 是 Forward Deployed Engineer 的缩写，本项目统一译为前线部署工程师：进入客户真实业务与技术环境，把尚未标准化的能力做成可运行、可验证、有人采用的生产流程。这个角色要做的事，可以按四个维度来评估。
一、架构拆解不先定，后面全在错的地基上动工
第一个维度决定成本和上限。
同一个需求，有几种做法。经办人员问"这笔订单到哪了"，查一次接口就能答，单次调用足够。合同审批要先取合同、比对条款、查历史同类件、生成意见，再送人复核，这是一条固定流程，交给一次调用很难稳定。再往上，尽调、投研这类任务连流程都不固定，才需要几个智能体分工：一个取数、一个核验、一个成文。
判断错在哪一端都会付代价。简单任务硬上多智能体，是给自己加运维负担；复杂任务硬压成单次调用，是把不确定性藏进一个黑盒里，出了问题连该修哪里都说不清。
所以这一维度不必问"你会用多少种框架"。该问的是：这个问题你判断落在这三种结构的哪一种，理由是什么。 顺着再追问三件事：流程拆成几步、每步输入输出是什么、哪一步失败能重来。答得出来，说明他真的拆过；答不出来，后面的工具和评测都无从谈起。
有一条原则值得单独记：结构先选简单的，能组合就不要嵌套。多一层智能体，就多一层失败点、一层调用成本、一处要写日志的地方。
二、工具与上下文工程：模型答错，多半是喂给它的东西有问题
第二个维度管的是"怎么把活干成"。
智能体与普通接口调用的区别，在于它要自己规划步骤、挑工具、记住前文、连跑多轮。这四件事每一件都是工程活，不是提示词活。
工具的 Schema 要写清楚：参数什么类型、必填哪些、权限边界在哪、超时怎么处理。这里粗糙，模型就会乱调：该查 A 表去查了 B 表，该只读的去写了。很多智能体上线后不稳，复盘下来根子不在模型，在工具描述含糊、异常没定义。
上下文是另一半。我们见过一种做法：把历史对话全部拼进去，觉得信息越全越好。结果是长对话里旧内容挤掉了关键内容，模型反而挑错表、答错口径。正确的做法是按当前任务主动装配：这一轮需要哪些数据、哪些规则、上一个环节交付了什么，其余的不进上下文。
我们的经验是，一个智能体第二轮开始走样，先查上下文和工具，别急着换模型。这两处调好，通常比升级模型版本见效更快。
三、没有测评集，你说不清它今天比上周好还是坏
第三个维度是被低估最多的一项。它不产出看得见的功能。
传统软件改一行代码，影响范围大致能圈出来。智能体不一样：改一句提示词、换一次模型版本，可能修好一些问题，同时引入新问题。没有一套固定考题，就只能凭感觉说"好像变好了"。
合格的评测集是一套带标准答案的真实业务题：这句话该不该拦、这个数该不该取、这条结论引用得对不对。题目由业务专家出，本质是把专家的判断标准固化下来。每次改动后完整跑一遍，分数掉了就拦住不上线。没有这套机制，系统上线那天就是它的能力上限。
可观测性解决另一半问题：出错之后能不能定位。每次调用记下什么：用了哪些材料、走了哪条路径、在哪一步停住、结论从哪来。没有这条链路，系统对使用者就是个黑盒，只能反复重试去猜。
四、生产可靠性：能不能暂停、恢复、审计、回滚
第四个维度决定系统能不能真的进生产。停在演示间里的系统，缺的正是它。
演示环境里没人和你抢资源，没有断网，也没有隔一段时间再接着跑的旧任务。生产环境全都有。所以要看这四件事：
暂停，任务跑到一半能不能停下来等人确认；恢复，服务重启或中断之后能不能接着跑，不必从头再来一遍；审计，每一步谁发起、用了什么材料、给了什么结论，能不能查；回滚，这版出了问题，能不能退回上一版。
这四件之外还要配三样：成本和延迟有上限，防止单个任务持续消耗超出预算；误操作有防护，写操作与删除操作要分级；人机边界写清楚，哪些决策智能体不能自己拍板。金融、担保这类场景还要加上留痕要求。留痕通常是验收条件，不能等上线后再补。
四个维度是两组，别只盯前一半
前两个维度管"做不做得出来"。架构拆解决定结构对不对，工具与上下文决定单次执行质量如何。这两样不过关，你连一个能跑的演示都拿不到，问题暴露得早，也容易修。
后两个维度管"做出来的东西能不能用"。评测与可观测决定系统能不能改、出错能不能查；生产可靠性决定它能不能在真实环境里长期运行。 这两样不过关，你手里会有一个演示很漂亮、上线就卡死的系统，而且没人说得清错在哪。
麻烦的地方在于，后两个维度在项目前期几乎没有存在感。它们不产生界面、不产生功能清单，报价单上也看不出差别。等系统上线出了问题再回头补，返工成本已经明显增加。同一批人做出来的东西，有的能长期运行，有的很快没人敢碰，差别多半就出在这里。
判断顺序可以倒过来：先问后两项有没有安排，再谈前两项做得多精致。一个上场前就想好怎么退场的团队，通常更值得托付。
一份现场评估清单
下次面试或评审方案时，把这几个问题问出去，答案的质量会分层：
- 这个需求，你判断该用单次调用、固定流程还是多智能体？为什么？
- 流程拆成几步？每步的输入输出是什么？哪一步失败可以重来？
- 工具的权限边界在哪里？超时和异常怎么处理？
- 下一轮对话需要哪些信息？由谁决定放什么进上下文？
- 评测集谁来出题、多少道、每次改动是否完整回归？分数掉了拦不拦？
- 出错以后，多久能定位到是哪一步、被哪条材料带偏的？
- 能不能暂停、从断点恢复、审计、回滚？成本和延迟的上限是多少？ 这些问题的答案，比候选人报得出多少个框架名字更能说明问题。
评估服务方时也适用同一套。可信金科的 FDE 工程师进到客户现场，先跟业务专家把流程走一遍，定清楚拆成几步、哪几步留人签字、上线后拿什么题回归验证。从演示到生产之间隔的不是模型，是这四件事有没有人管。
