做企业 AI，迟早会遇到一个问题：每个客户的需求都不一样，难道每次都要派一队工程师重新做一遍？
如果回答是“招更多 FDE”，那交付能力仍然主要取决于能招到多少复合型人才。
我们做 Tacore 时选择了另一条路：把实施经验沉淀为工具，让 Coding Agent 承担更多系统建设工作。最近看 Palantir 的 AI FDE，我觉得值得讨论的也是这件事——交付过程中的哪些能力，已经可以变成产品？
先看 Palantir 做了什么
根据 Palantir 官方文档，AI FDE 能通过自然语言操作 Foundry，处理数据转换、代码仓库、Ontology 和函数等工作。它可以观察工具执行结果，继续采取下一步动作，也能用预览和检查验证修改。操作受用户现有权限约束，默认通过分支或拉取请求提交变更供审核。AI FDE 官方文档
值得注意的是，它面对的环境已经有明确的对象、工具和检查机制。
Agent 知道自己在修改什么，知道有哪些合法操作，也能获得修改之后的反馈。这些条件让“帮我调整系统”成为可执行任务。
从这个角度看，给 FDE 配一个代码助手，只完成了其中一部分。更深的变化是：把原本依赖工程师手工操作的工作环境，改造成 Agent 能够使用的产品。
为什么本体和上下文很重要
企业数据表里都有字段，为什么还要强调业务对象和关系？
因为字段名并不等于业务含义。
同一个订单，销售说已成交，财务说未收款，生产说已排产，三个状态可以同时成立。如果 Agent 把它们当成互相矛盾的三个版本，后续判断就会出问题。
它需要知道：这是同一个订单的不同业务维度；什么动作可以改变哪个状态；哪个角色有权限执行；变更以后会影响什么。
Palantir 在 AIP 架构中，将 Ontology 描述为连接数据、逻辑、动作和安全控制的统一业务表示。AIP 架构说明
对应到自己的系统设计，可以先检查几个具体问题：
| 层面 | 需要明确的内容 |
|---|---|
| 对象 | 客户、订单、供应商怎样唯一识别 |
| 关系 | 订单属于谁、使用哪些物料、依赖哪个供应商 |
| 状态 | 已报价、已批准、已成交分别代表什么 |
| 动作 | 谁能改价格、谁能确认订单、什么条件下允许执行 |
| 来源 | 事实来自哪里、更新时间是什么、出现冲突听谁的 |
这些定义落实以后，Agent 才有条件理解一个修改的业务影响。把更多原始文档塞进上下文窗口，并不能自动得到这些关系。
把“老师傅经验”拆成能调用的工具
我们把自己的产品分成两个互相配合的部分。
企业 AI OS 承载业务：知识库、数据、规则、工作状态，以及人和 Agent 共用的业务系统。
AI FDE 工具箱负责建设和调整这些能力，供 Coding Agent 使用。它包含实施经验、工程约束，以及连接、开发、测试、部署等工具。
拿一个报价需求说明：业务人员希望采购维护成本，销售按最新成本报价，低于毛利要求时先审批。
交给 Agent 的不能只有“做一个报价系统”这句话。工具箱要帮助它沿着一条可验证的过程往前走。
先理解现有环境。 成本从哪里来？已经有哪些业务接口？当前角色和权限是什么？已有能力可以复用，就不应该重新造一套。
再把规则落实成业务约束。 哪个成本版本用于计算，报价在什么时候需要审批，批准后允许做什么，都要有明确的状态和服务端校验。
然后开发和验证。 界面、工具调用、业务服务应使用一致的规则。销售通过聊天报价和通过页面报价，不能得到两套结果。
最后部署并检查业务结果。 页面能打开只是第一步，还要确认对应角色能完成任务、记录确实保存，以及后续查询能读到同一条记录。
Agent 在每一步都应该拿到明确回执。缺成本就是缺成本，权限不足就是权限不足，不应把这些业务失败包装成“操作成功”。
最值得产品化的，是验证和恢复
AI 生成代码的速度很快，但如果只有生成环节变快，后面的人工排查可能变得更重。
所以，评价 AI FDE 工具箱时，我更关心它怎样发现自己做错了。
还是报价系统。至少需要验证正常报价、成本缺失、越权读取、低毛利审批、重复提交这些情况。特别是失败路径，往往比正常路径更能暴露是否具备生产条件。
这里还有一个容易忽略的问题：不能把固定测试答案写进 Agent 的日常岗位提示词，再用同一组答案证明它“业务能力很好”。测试材料和正式业务上下文应该分开，验证才有意义。
发布之后也一样。一次工具调用超时，不代表业务一定没执行；直接重试可能造成重复写入。更合理的做法是根据请求标识查询执行结果，再决定是否重试。
可恢复的执行记录、版本记录和审计，会让后续维护更可控。涉及外部发送、付款等不可逆动作时，还需要相应的审批或补偿设计，不能把“能回滚代码”误当成“能撤销业务结果”。
这些事情看起来没有生成页面那么惊艳，却决定客户第二天还敢不敢继续使用。
业务人员自己建设系统，意味着什么
我们的目标，是让懂业务的人可以借助 AI 自己建设和调整系统，降低对专门实施团队的依赖。
业务人员需要讲清楚目标，提供必要资料和授权，确认规则，检查结果。Coding Agent 借助工具箱处理工程工作。
这种分工有一个前提：系统必须把需要人判断的事情表达清楚。例如两份成本表有冲突，就应该展示差异和来源，让负责人决定；不能因为用户不会写代码，就让模型悄悄替企业制定规则。
对做开发的人来说，机会也在这里。你熟悉某个行业里反复出现的需求、接口、异常和验收方法，就有机会把这些经验做成 Agent 可以使用的工具。
最后还是要看结果：下一家客户是不是少了一批重复开发，下一次业务变化是不是能更快完成验证，同一套工具是不是持续变得可靠。
实施经验能够复用到这个程度，FDE 产品化才开始成立。
本文是「企业 AI：从交付到上下文」系列第二篇。Palantir 部分依据公开文档；Tacore 部分为我们的产品思路与实践，不代表双方存在合作关系。下一篇继续讨论：当 Agent 和模型都可以更换，企业应该把什么长期留在自己手里。
