一个toB Agent入职的第一天，会发生什么？
如果厂里新来了一位经验丰富的工程师老张，我们通常不会在第一天就安排他接管生产。老张需要先理解这个工厂是如何运转的，比如：
这条产线是怎么运行的？哪些指标最重要？哪些操作有严格的安全边界？遇到异常时，师傅们通常怎么处理？
更重要的是，很多关键知识并不写在制度、SOP 或系统字段里。比如：
某个设备最近状态不稳定，某个参数需要结合原料批次进行调整，又或者某两个工段之间存在只有现场人才知道的联动关系。
在某种意义上，2B Agent 的部署上线，也是一场正式的“入职”流程。它需要学习工艺，理解规则，认识协作关系，并逐渐形成对生产系统的整体认知。
所以，2B Agent 产品的交付，从来不只是部署一个模型、一个 Agent 应用或一个平台，而是在帮助一个 AI 员工真正融入进生产经营的现场。
01
ToB 智能体的交付不是单纯的软件部署，
而是多种软硬能力的综合性交付过程
过去一年，我们做了不少 2B Agent 项目，尤其是针对生产型企业的各类场景。
回头看，一个项目能不能成功、上线前后大家反复讨论的，往往不是模型精度，也不是参数量，而是一些听起来并不那么“AI”的问题。比如：
生产经营系统当前最重要的生产目标是什么？
哪些变量之间隐藏着底层系统写定的耦合关系？
什么情况下应该优先切回人工接管（Human Control）？
什么情况下可以适当降低出品率要求，优先追求经济性？
这些知识，一部分我们可以从企业生产系统的数据中观察到；而另一部分则来自工艺文档、操作人员多年积累的经验，以及产线长期形成的运行习惯。
接下来，问题会迅速从工艺是什么转向系统本身：
数据到底在哪里？哪些测点可获得？哪些数据长期漂移，是稳定地漂，还是随机地漂？ERP、MES、DCS、MIS 里的同一个指标，为什么口径不一致，以谁为准？哪些 API 可以开放读取，哪些回路权限允许回写？
再往后，才是大家想象中的“AI 工作”：
数据需要重新治理，工况需要重新定义，异常样本需要重新标注或剔除，模型和工作流也需要根据现场目标不断调整。
即便模型上线，工作也没有结束。真正的经营管理问题会继续浮现：
不同层级的用户到底希望这个智能体帮他做什么？是最初期待的稳定生产、降低能耗、减少人工干预，还是随着使用深入后产生了新的理解和期待？
不同目标设定，也会直接决定智能体的行为方式。
到这里，一个 Agent 项目的性质其实已经不同了：
它不再是某个或某几个生产单元的优化问题，而是一连串翻译问题：把现场语言翻译成数据定义，把业务目标翻译成模型边界，再把模型能力翻译成现场能接受的工作方式。
传统软件项目里，很多问题可以沿着岗位边界往下分发。但到了 Agent 类项目里，这种分发反而会制造断点 - 工艺口径没有进入数据定义，数据限制没有进入模型边界，客户目标没有进入工作流设计，最后都会变成“模型效果不好”。但真正的问题未必全都在模型。
我们后来讨论 FDE，其实就是从这些断点开始的。
我们在不断被现场情况推着去回答一个更实际的问题：
谁能来保证现场经验和知识内化到Agent能力的过程中没有走样？是一个人还是一组人？
02
FDE 不是单纯把几种岗位合成一个人
很多人对于FDE这个角色的理解，会以为它要求一个人同时成为算法工程师、产品经理、项目经理和行业专家。真这样理解，反而把问题想窄了。
在很多工业项目里，我们面对的是这样的场景：项目刚开始时，大家以为最需要的只是算法工程师。但真正进入现场之后，算法工程师很快发现，自己面对的不只是数据处理和模型调优。上午他可能在还在和客户梳理工艺流程，下午就要协调点位确认和数据库接入，晚点又回去调整模型特征和工作流。
但这并不意味着他要把所有岗位都做一遍。更准确地说，他需要形成一条判断链：哪些变量能信，哪些操作不能放给 Agent，哪些经验可以写成规则，哪些只能作为提醒留给人来判断。
FDE 的价值就在这条判断链里……
把现场理解、系统接入、模型边界和产品实现融会贯通，让 Agent 的每一次动作都能回到真实约束里，可被信赖地参与到生产执行中去。
03
属于中国的2B FDE，会是什么样子？
Palantir 的 FDE 诞生于硅谷的工程文化和高客单价环境中，但中国工业项目的现实并不完全相同。我们的项目周期更短，行业差异更大，客户更加关注投入产出比，也更依赖本地实施和行业经验。很难想象大多数工业企业会长期为一支高成本的驻场专家团队买单。
但另一方面，我们又越来越强烈地感受到，toB Agent的落地确实需要一种新的能力出现。
这种能力需要走进现场，但又不能停留在现场；需要理解工艺和业务，但又不能依赖少数专家的个人经验；需要帮助智能体理解真实世界，同时还要让这种理解能够被复制、被积累，并在下一个项目中继续创造价值。
某种意义上，我们并不是在寻找一个中国版的 Palantir FDE，而是在寻找一种更适合本土工业场景的能力组织方式。
04
并不是先定义了FDE，再去寻找这样的人
恰恰相反，这个角色是在一次次项目实践中逐渐浮现出来的……
我们最早寻找的是超强的算法工程师，希望他们能够把模型做好；后来发现，模型效果的瓶颈往往不只在算法本身，而在于对现场的理解。
于是，我们开始要求工程师进入工厂，和工艺人员一起讨论工况、看趋势、理解生产逻辑。
再后来，我们又发现，仅仅理解工艺仍然不够。很多问题的根源来自系统之间的割裂、数据口径的不一致、不同部门之间目标的冲突，以及那些从来没有被文档记录下来的隐性经验。
随之而来，有一些工程师开始自然而然地，或主动或被动地跨越岗位边界……
他们会在和工艺工程师讨论完控制逻辑之后，回去调整工作流；会在处理数据问题之后，继续追问这个指标背后的业务意义的合理性是什么；会在项目交付结束后，主动思考这些经验能否沉淀成行业通用的模型和产品能力。
慢慢地，我们发现，我们正在寻找的并不是某一种专业背景，而是一种新的人才能力涌现。
05
Inudustrial FDE的核心绝不是陪伴式“驻场”
真正重要的是，如何把现场变成一个可学习的系统。
工业 AI 的交付当然需要靠近现场，因为大量关键知识都存在于现场工程师的判断、操作员的习惯、设备长期运行的异常经验，以及企业内部复杂的协作关系里。
但如果这些知识始终依赖少数专家长期驻场，它就很难规模化。
因此，本土式的「Be There」交付，不应该只是人出现在现场，而应该是把现场的知识不断转化为：
可以理解的对象
可以执行决策边界
可以复用的工作流
可以沉淀的行业能力
让每次项目中的经验，不会随着项目结束而消失，而能够持续进入到产品和智能体能力之中。
06
我们越来越相信，Agent时代的竞争力，长期来看不在底层模型，而是能够持续完成这种转化的人才
过去，企业的核心能力往往沉淀在少数专家的大脑里。未来，越来越多的能力会被结构化、被表达、被复制，并成为企业可以反复调用的数字能力。
这意味着，对于人才来说，行业需要的不再只是单一工种的专家，而是能够跨越工艺、系统、数据和业务边界的复合型工程师。
而对于企业用户来说，挑战也不再只是购买一套软件，而是如何建立一支能够持续理解现场、持续训练智能体、持续沉淀组织能力的新型Agent时代人才梯队。