人工智能16 分钟阅读
Palantir AI FDE 新增 Automate：Agent 现在可配置企业工作流
Palantir 8 月 27 日的更新为 AI FDE 增加了 Automate 工具，使 Agent 能够在受治理的分支与审批体系内创建和修改业务自动化——定义触发条件、动作、重试和回退——推动企业 AI 从问答走向工作流编排。
从“回答问题”到配置“当此事发生，就执行彼事”
8 月 27 日，Palantir 为 AI FDE（AI 前沿部署工程师）更新了 Automate 工具。Automate 是 Palantir Foundry 的业务自动化产品，其核心逻辑是“当此事发生，就执行彼事”。用户定义条件（Condition），这些条件会持续或在计划时间被检查——基于时间或基于 Ontology 中的对象数据。当条件满足时，系统自动执行一个或多个效果（Effect）。效果可以调用 Foundry Action、AIP Logic、Functions，或发送平台通知和电子邮件。Automate 还提供顺序/并行执行、重试（Retry）和回退（Fallback）机制，以控制自动化链的运行方式以及失败时的处理方式。
更新后，AI FDE 可以直接参与这一配置过程。根据 Palantir 官方文档，AI FDE 现在可以配置时间计划和对象集条件，使用 Foundry Action、AIP Logic 和通知效果，并设置输入参数、执行模式、顺序或并行执行、重试和回退。它还可以创建和管理用户级或项目级自动化，并执行暂停、恢复、到期和静音操作。因此，以前需要工程师跨多个资源进行配置的流程，现在可以通过自然语言在单次会话中完成。例如，一个订单异常流程——“订单异常 → 判断对象状态 → 提交 Action → 通知负责人 → 失败时重试或回退到备用处理”——可以由 AI FDE 在理解相关 Ontology、Action、Function 和 Automation 的情况下生成或调整。
不同于编码 Agent：它修改的是“软件如何运行”
编码 Agent 已将自然语言变成软件开发的接口：开发者描述需求，Agent 读取代码库、修改代码、运行测试，并将变更交给现有的开发流水线。它们解决的是“代码如何编写”的问题。
然而，企业系统中包含的关键逻辑并不只存在于代码文件中：某种订单类型是否应该升级处理、库存低于阈值时通知谁、失败后重试多少次、何时启动备用流程、哪些动作必须串行执行而哪些可以并行执行。这些更接近企业运营规则和业务编排。
Palantir 的架构让这条链路十分清晰：Ontology 组织对象、属性、关系和 Action 类型；Functions 承载可复用的业务逻辑；Actions 定义对对象的结构化修改；Automate 决定哪些 Conditions 触发哪些 Effects。当 AI FDE 在这些资源之上工作时，自然语言的覆盖范围就从“代码实现”扩展到了“业务运行逻辑”。两种模式可以简化为：
Coding Agent：业务需求 → Prompt → 代码
AI FDE + Automate：业务需求 → Ontology / Action / 逻辑 → 自动化
这并不意味着传统代码消失；Functions、Actions 和 Ontology 仍然承担底层约束和业务逻辑，但工作流的编排与配置现在由 Agent 参与。Agent 不再只修改代码仓库，而是修改“何时调用哪个能力、失败时怎么办、流程如何继续”。
企业级 Agent 的新能力：编排权
此前，Agent 的能力往往以它能连接的 Tool 数量来衡量：数据库查询、SQL 执行、邮件、ERP 调用、内部 API。Tool 越多，执行范围越大，但“调用一个工具”和“配置工具之间的关系”是两回事。
如果一个 Agent 只能调用库存查询工具，它仍然是一个执行者。如果它能根据业务需求配置触发条件，决定多个 Actions 和 Logic 的执行顺序，设置 Retry、Fallback 和作用范围，那么它就参与了工作流编排。
Automate 的执行机制本身已经是一个接近完整的业务工作流引擎。一个 Automation 中的 Effects 可以顺序执行或并行执行；在顺序模式下，前一个 Effect 失败会阻止对象进入后续步骤；主 Effect 可以配置 Fallback，单个 Effect 支持自动 Retry。Palantir 还提供事件级别的 Retry，以及控制并发和队列执行的设置。
通过接入 Automate，AI FDE 获得的不只是调用单个系统的权限，而是配置这些执行关系的能力。对企业级 AI 来说，这比增加 Tools 更进一步：Agent 从“执行一个任务”走向“构建一条可持续运行的任务链”。
Palantir 不让 Agent“裸改生产环境”：分支与审批
一旦 Agent 能够配置业务自动化，问题就从“能不能做”变成了“如何安全地做”。代码变更通常有测试和 CI 保障；而工作流配置的变更会直接影响真实的订单、库存、告警、审批和通知。
在此次更新之前，Palantir 已经为 Automate 添加了类似软件工程的变更机制。7 月 9 日，Automate 宣布推出 Global Branching：开发者可以在 Branch 上添加、修改或删除 Automation，在隔离环境中运行端到端测试，然后通过 Proposal、Reviewer 和 Approval Policy 进行审查，最终合并到 Main。Branch 还支持 Rebase，以处理 Main 上已经发生的变更。
8 月 27 日的 AI FDE 更新延续了这一机制。官方发布说明指出，AI FDE 可以在 Main 或 Global Branch 上创建和编辑 Automation。Palantir 的方向并不是简单地给 Agent 一个修改生产配置的入口，而是把 Agent 的修改纳入现有的分支、测试、审查和合并流程。这与 Coding Agent 进入软件工程的路径如出一辙：最终决定 Agent 能否进入核心系统的，不仅仅是模型的生成能力，而是是否存在版本控制、权限、测试、审查和回滚等防护机制。当 Agent 开始修改企业运营规则时，这些工程防护机制就变得更加关键。
还不是“Agent 接管生产”，但边界已经前移
此次更新仍有明确的能力边界。AI FDE 目前无法配置所有 Automate 条件——时间序列、流、数据集、指标变化和指标阈值条件尚不支持。在 Effect 方面，Foundry Function Effect、Agent Effect 以及部分基于 Function 的 Notification 也不受支持。此外，AI FDE 无法为现有 Automation 添加 Effect，也无法直接查看 Automation 运行历史、手动触发执行或访问 Telemetry。因此，将此次更新描述为“Agent 已完全接管生产流程”并不准确。更准确的说法是：Palantir 正在让 Agent 进入业务自动化的创建和配置层，并逐步将这类变更纳入可治理的工程流程。
这厘清了企业 Agent 的演进路径：第一阶段——对话（“告诉我发生了什么”）；第二阶段——工具使用（“帮我执行一个操作”）；Coding Agent 将其推进到“帮我修改软件”；AI FDE + Automate 则展示了下一层——“帮我配置企业系统如何持续运行”。
随着自然语言进一步延伸到 Ontology、Action、Logic 和 Automation，企业 AI 的核心问题也随之转变：竞争不再仅仅是模型能否回答问题或调用工具，而是它能否连接业务语义、可执行能力、流程编排和治理机制。Agent 真正进入企业核心系统的关键，可能不在于更多的 Prompt，而在于一个可以被安全修改、测试和审计的运行时层。
参考资料
https://www.palantir.com/docs/foundry/announcements/
— Palantir Foundry 公告：在 AI FDE 中使用 Automate 配置业务自动化（2026-08-27）
https://www.palantir.com/docs/foundry/ai-fde/overview/
— Palantir AI FDE：概述
https://www.palantir.com/docs/foundry/automate/
— Palantir Automate：概述
https://www.palantir.com/docs/foundry/automate/effects/
— Palantir Automate：效果
https://www.palantir.com/docs/foundry/automate/effect-settings/
— Palantir Automate：效果设置
已登录的读者可以通过 BestHub 的受保护跳转链接打开原始来源。
本文由原始资料提炼、总结后转载，仅供学习与参考之用。如您认为其侵犯了您的权益，请联系我们，我们将及时处理。
DataFunTalk
致力于分享和探讨大数据与 AI 技术应用，旨在赋能百万数据科学家。定期举办技术直播，并整理大数据、推荐/搜索算法、广告算法、NLP、智能风控、自动驾驶以及机器学习/深度学习等领域的文章。
这篇文章在社区中的反响
这篇文章值得您花时间吗？
0 条评论
有深度的读者会在这里留下实地笔记、不同意见以及来之不易的实操细节。