写在前面

现在很多企业软件接 AI，第一反应是加一个聊天框。

用户问一句“这个月哪个区域异常”，系统给一段解释；再问“我该怎么处理”，它给几条建议。这个体验比翻菜单快，也比读报表舒服。

所以聊天框会存在。它解决了一个真实问题：用户终于不用先学会系统怎么组织页面，才能表达自己想做什么。

但做企业软件的人都知道，提问只是前半段。用户问完之后，通常还要回到旧流程里：找入口，填字段，确认规则，发起审批，等系统回写，再过几天看结果。

如果这条链路没有变短，AI 再会说，也只是把帮助文档写得更像人。这就引出一个更具体的问题：AI Agent 怎么进入企业软件？

它应该只是一个更聪明的入口，帮用户问数、找功能、解释规则；还是应该往后再走一步，进入业务动作本身？

这个问题不能只用模型能力回答。模型能不能理解一句话是一回事，企业软件有没有把业务对象、动作、权限和结果做成可调用的能力，是另一回事。

对 B 端产品来说，真正难的地方往往不在“生成一个方案”，而在方案之后：谁确认，谁执行，执行错了谁接管，结果怎么复盘。

从聊天框到业务动作，中间到底缺了哪几层产品设计。

一、聊天框是入口，不是答案

聊天框解决信息摩擦，业务动作链才真正缩短企业软件里的处理流程。

聊天框当然有价值。很多 B 端系统的问题，不是功能不够，而是用户不知道功能在哪里。一个销售、运营、财务、商家或者门店老板，面对一套复杂系统时，最常见的状态不是“我要用哪个高级功能”，而是“我现在有个问题，但不知道该点哪里”。

自然语言入口能解决一部分痛苦。

以前用户要先理解系统结构，再把自己的问题翻译成系统里的菜单、字段和筛选条件。现在他可以直接问：“这批订单为什么异常？”“这个活动还能不能继续投？”“这个商家的利润为什么变差？”系统如果能听懂，并把相关数据、规则、历史动作调出来，体验会好很多。

但入口变简单，不等于业务变简单。这也是很多企业软件接 AI 时容易高估的地方。聊天框让用户更快抵达答案，可很多 B 端场景里，答案本身不是终点。查到库存异常之后，要调拨；看到经营下滑之后，要改活动；发现补贴亏损之后，要停投或者换策略；看到某个门店出问题之后，要派人处理，还要追踪处理结果。

如果 AI 只是把“发生了什么”解释清楚，后面的动作仍然要人自己跨系统完成，那它解决的是信息摩擦，不是流程摩擦。

企业里真正贵的，往往是动作链太长。一个问题从发现到处理，中间要经过好几个角色、好几个系统、好几次确认。每个人都只做一小段，交接时丢一点上下文，过两天再回来看结果，已经说不清当时为什么这么做。

聊天框无法自动消灭这些交接。它能把“你应该做什么”说得更明白，但如果系统没有把“做这件事”的能力暴露出来，没有定义谁能做、做到哪一步、做错了怎么退、做完以后怎么验收，Agent 就只能停在建议层。

这不是模型不够聪明。这是企业软件本身还没有准备好被 Agent 调用。

所以讨论 AI Agent 进入企业软件，第一步不是问“要不要加聊天框”。更值得问的是：用户问完以后，系统能不能继续往后走一步？

• 能不能从解释异常，走到生成处置方案。

• 能不能从推荐活动，走到利润测算和报名确认。

• 能不能从经营诊断，走到任务下发、动作执行和效果复盘。

如果不能，那这个 Agent 更像一个会说话的帮助文档。帮助文档可以更聪明，但它还不是新的企业软件形态。

二、Agent 真正进入企业软件，要先进入业务动作

过去的 B 端产品，大部分是在组织页面。

一个系统里有什么对象，就给它建一个管理页；一个流程里有什么节点，就给它做一个审批页；一个经营问题要看什么指标，就给它做一个看板。

这套方式并不落后。它解决了企业软件过去二十年最重要的问题：把线下流程搬到线上，把口头协作变成系统记录，把谁能看、谁能改、谁审批这些事情固化下来。

但 Agent 进来以后，它遇到的不是“页面不够多”的问题。它遇到的是：这些页面背后的业务能力，能不能被调用。

举个简单例子。

一个商家，有门店、商品、菜单、活动、补贴、预算、配送范围、评价、异常工单。它们都是业务对象。传统系统会把这些对象分别放在不同页面里，让人去查、去筛、去编辑。

Agent 要做事，只知道这些名词还不够。它还要知道这些对象上能发生什么动作。

• 商品能不能改价，改价需要谁确认？

• 活动能不能报名，报名之前要不要测算利润？

• 补贴能不能调整，调整后怎么判断是不是亏钱？

• 异常能不能自动派单，派给谁，多久没处理要升级？

这些才是 Agent 真正需要的东西。

如果一个系统只有对象，没有动作，Agent 就只能查资料。它可以告诉你“这个商品最近转化下降”“这个活动 ROI 不好”“这个商家可能有异常”，但它没法继续往后走。因为系统没有给它一条可执行的路。

如果一个系统有动作，但没有权限和验收，Agent 又会变危险。它可以改价、报名、停投、派单，但谁授权？谁负责？做完以后怎么判断这次动作是对是错？

所以企业软件接 Agent，不只是多做一个自然语言入口，也不是把所有 API 暴露给模型那么简单。

更像是把业务世界重新整理一遍：哪些是对象，哪些是动作，哪些动作可以自动，哪些动作必须确认，哪些动作做完以后要回收结果。

Palantir 的 Ontology 之所以经常被拿来讨论，原因也在这里。它有参考价值的地方，不是名字听起来高级，而是它把企业里的数据对象、关系和动作放在一个业务世界里建模。AIP 或 AI FDE 再往上做自然语言操作、工具调用、权限约束和执行记录。

这给 B 端产品一个提醒：Agent 要进入生产系统，前提不是界面像不像 ChatGPT，而是底层业务能力有没有被组织成“可理解、可调用、可追踪”的形态。

对我们来说，这会改变设计问题。以前设计一个功能，常问的是：用户从哪里进入，页面怎么排，字段怎么填，审批怎么流转。

以后可能要多问几句：这件事能不能被 Agent 拆成动作？每个动作的输入和输出是什么？动作执行前要不要人确认？执行后结果回到哪里？下一次策略能不能复用这次结果？

这些问题听起来更麻烦。但这正是企业软件和普通聊天产品的分界线。

聊天产品关心“用户说了什么”。企业软件还要关心“系统替用户做了什么，以及做完以后留下什么记录”。Agent 能不能进企业软件，不只看它会不会理解一句话。更要看企业软件有没有把业务动作做成它能调用的能力。

三、商家侧产品给了一个具体问题：AI 是给建议，还是把动作跑完

商家侧 Agent 的价值不只是生成建议，而是推进一段可确认、可回写、可复盘的经营动作。

商家侧产品是一个很适合观察 Agent 的场景。因为这里的问题足够具体，也足够琐碎。它不像“企业智能化转型”那么大，落到商家身上，往往就是几个很现实的问题：菜单怎么改，活动报不报，补贴亏不亏，异常谁处理，下一周要不要换策略。

过去很多商家经营产品，主要做两件事。一是把经营状态展示出来。比如订单、曝光、转化、客单价、复购、差评、配送、活动效果。二是给一些建议。比如哪些商品表现不好，哪个活动可以报名，哪个时段需要加预算，哪个异常需要关注。

但商家真正被卡住的，经常不是“不知道问题在哪里”，而是“知道了以后还要自己做很多事”。

• 菜单结构不好，不只是生成一句“建议优化菜单”。后面可能要补图片，改商品描述，调整分类，测算价格，确认是否影响毛利，再提交回系统。

• 活动可以报名，也不只是告诉商家“这个活动适合你”。后面要看活动规则，算补贴成本，估订单增量，判断亏不亏，确认预算，再报名，最后还要复盘效果。

• 补贴投放也是一样。看板能告诉你花了多少钱，转化怎么样，但真正有价值的问题是：这笔补贴到底买来了什么？下一轮应该加、减、停，还是换一类商品投？

• 异常处置更明显。系统发现异常，只是第一步。后面要判断是谁的问题，派给谁处理，多久处理完，处理结果是否回写，是否影响下一次策略。

所以商家经营产品接 Agent，有一个很关键的分水岭：它是一个会生成建议的经营顾问，还是一个能把经营动作往前推的协作者？

这两个东西差别很大。经营顾问的交付物是“你应该怎么做”。协作者的交付物是“这件事已经推进到哪一步，还差谁确认，结果回来了没有”。

如果只做到前者，AI 的价值会被压在建议层。建议再好，商家仍然要自己理解规则、自己找入口、自己核算成本、自己等结果。对于能力强的商家，这可能有帮助；对于大量中小商家，它只是多了一份看起来聪明的报告。

但如果往后走一步，产品形态就变了。比如“菜单优化”不再是一个分析结论，而是一条动作链：识别问题商品，生成修改建议，补齐图片和文案，测算价格影响，商家确认，系统回写，七天后看转化变化。“活动报名”也不再是一个推荐卡片，而是一条动作链：匹配活动，解释规则，测算利润，提示风险，商家确认，发起报名，活动结束后复盘投入产出。

这里面每一步都不神秘。难的是把它们串起来。这也是为什么我觉得，商家侧产品比很多抽象的 Agent 讨论更有意思。它逼着我们把话说实。一个 Agent 不是因为能聊天就有价值，而是因为它能少倒几手、少丢几次上下文、少让人重复做同一套判断。

当然，这不代表所有动作都应该全自动。商家改价、活动报名、补贴调整，很多动作都涉及真实经营收益。早期更稳的方式，可能是 Agent 生成方案，系统做规则校验，商家或运营人员做关键确认，最后再执行和复盘。

这条路没有纯聊天框那么轻。但它更接近 B 端产品真正要解决的问题。商家不一定缺一个更会聊天的经营顾问。很多时候，他缺的是有人把一串经营动作少倒几手。

四、B 端 Agent 最难的不是生成方案，是承担动作后果

B 端 Agent 要进入生产系统，必须把权限、确认、兜底和复盘设计进动作链。B 端产品里，动作一旦发生，就会留下后果。这和普通聊天产品不一样。聊天产品答错了，最多让用户多问一句，或者换一个说法。企业软件里的 Agent 如果执行错了，后果会落到业务上。

• 价格改错了，影响商家收入。

• 活动报错了，影响平台补贴。

• 库存调错了，影响履约。

• 异常派错人了，影响处理时效。

所以 B 端 Agent 最难的地方，往往不是“能不能生成一个方案”。方案生成只是开始。真正难的是，系统敢不敢让它往后执行。

这里有四个问题绕不过去。

第一个是权限。Agent 能看什么数据，能调用什么工具，能替哪个角色操作？同样是“帮我优化这个活动”，商家、BD、运营、平台策略人员看到的数据不同，能做的动作也不同。权限如果不清楚，Agent 越能干，风险越大。

第二个是确认。不是所有动作都应该自动执行。查数、解释规则、生成草稿，可以自动多一点；改价、报名、补贴调整、营业状态变化，就应该有明确确认。甚至有些动作不应该由商家单独确认，还需要平台规则、风控或运营复核。

第三个是兜底。Agent 做错了怎么办？谁接管？能不能回滚？商家怎么知道？系统怎么记录？很多产品方案里会轻飘飘写一句“必要时人工介入”，但真正做系统的人知道，这句话不够。人工是谁，什么时候介入，介入以后看到什么上下文，能不能恢复到上一步，这些都要在产品里设计出来。

第四个是复盘。B 端动作不是做完就结束。一次活动报名之后，要知道订单有没有增长，毛利有没有变差，补贴有没有浪费；一次菜单优化之后，要看转化、客单、差评有没有变化；一次异常处置之后，要看问题是否真的消失。如果没有复盘，Agent 就不会变聪明。它只是不断生成新建议，不吸收旧动作的结果。

这也是为什么 Palantir AI FDE 这类产品会强调权限、工具可见性、操作记录和执行反馈。它给我们的启发不是“大家都应该做一个 Palantir”，而是生产系统里的 Agent 必须被治理。它调用了什么工具，看了什么数据，执行了什么动作，留下了什么结果，都要能追踪。

很多 Agent demo 看起来厉害，是因为它只演示了前半段。用户说一句话，Agent 拆任务，调工具，生成一个方案。这个过程很顺，很容易让人兴奋。

但企业软件真正困难的地方在后半段。

• 这个方案能不能执行？

• 谁来确认？

• 失败以后谁负责？

• 结果怎么进入下一轮判断？

这些问题没有回答，Agent 就很难从演示进入生产。这也是 Gartner 会提醒 agentic AI 项目存在取消风险的原因。很多项目不是死在模型不会回答，而是死在成本、业务价值和风险控制算不清。demo 能跑，不代表业务愿意把责任交给它。

B 端 Agent 不是越自动越好。它应该在能自动的地方自动，在需要人负责的地方把责任交还给人，在需要系统兜底的地方留下记录和回滚路径。企业软件里的 Agent，不是会不会说得像人。而是能不能像系统一样被治理。

五、产品单元可能会从功能模块转向业务动作包

业务动作包把触发、数据、方案、确认、能力、记录和复用打包成 Agent 可调度的产品单元。

如果前面这些问题成立，B 端产品接 Agent 时，一个可能的变化是：产品单元会从“功能模块”慢慢转向“业务动作包”。

功能模块回答的是：用户在哪里点，页面怎么组织，字段怎么填写，流程怎么流转。

业务动作包回答的是另一件事：一件业务动作能不能从发现问题，走到确认、执行、回写和复盘。

这两个视角不冲突。功能模块仍然会存在。企业软件不可能没有页面，也不可能所有用户都只用自然语言操作。很多高频、精确、批量的工作，页面和表格仍然更高效。

但 Agent 进来以后，只按页面组织能力可能不够了。因为 Agent 不会像人一样，一个页面一个页面地找入口。它更需要一组被打包好的能力：输入是什么，规则是什么，能调哪些系统，谁来确认，执行后去哪里看结果，失败了怎么退。

这就是我说的业务动作包。它不是一段 prompt，也不是一个单独按钮，更不是把几个 API 粘在一起。一个动作包至少要回答七个问题：

① 这件事从什么信号触发？

② 需要哪些业务数据？

③ 可以生成哪些方案？

④ 哪些动作能自动执行，哪些必须确认？

⑤ 会调用哪些系统能力？

⑥ 执行结果怎么记录？

⑦ 下一次策略怎么复用这次结果？

如果这些问题答不出来，Agent 就很难稳定做事。它可能每次都能生成一段看起来合理的话，但每次都要人重新判断、重新确认、重新找入口。这样用久了，用户会觉得它聪明，但不省事。

OpenAI 的 Skill、Plugin，Cursor 的 Plugin，都能给我们一点启发。它们在开发者工具里的做法，不是只给 Agent 一段提示词，而是把工作流、资料、脚本、工具连接、权限和分发方式打包起来。这样 Agent 才能从“知道怎么说”，变成“知道怎么做”。

企业软件里的动作包会更重。因为它不只要会调用工具，还要处理业务责任。一个菜单优化动作包，不只是“生成菜单建议”，还要知道商品结构、图片规范、价格边界、商家确认、系统回写和效果复盘。一个活动报名动作包，也不只是“推荐活动”，还要理解活动规则、测算利润、提示风险、发起报名、跟踪投入产出。

这时候，B 端产品要设计的就不是一个 AI 助手，而是一组能被 Agent 调度的业务能力。这会改变产品规划的顺序。

过去可能先想模块：商家管理、商品管理、活动管理、补贴管理、异常管理。以后可能要先想动作：新商家怎么冷启动，菜单怎么优化，活动怎么报名，补贴怎么复盘，异常怎么处置。

模块是系统视角。动作是用户视角，也是 Agent 更容易接住的视角。

当然，不是所有动作都值得打包。这里仍然要克制。低频、责任重、收益不清的动作，先不要急着 Agent 化。更适合先做的是高频、边界清楚、结果可验证、失败可兜底的动作。

比如商家侧产品里，“菜单信息补全”“活动利润测算”“补贴效果复盘”“异常任务派发”，可能都比“全自动经营商家”更适合作为起点。

先把一个动作跑通，比做一个大而全 Agent 更重要。因为企业软件里的信任不是靠演示建立的。信任来自一次次动作真的完成，结果能回收，错了能找回来。

所以 B 端产品应该怎么做？我现在更倾向于一个朴素的顺序：

先选一个具体动作。再定义它的输入、输出、权限和确认。然后接系统能力，做结果回收。最后再考虑是否让 Agent 编排更多相邻动作。

现实的企业软件，大多就是这样长出来的。功能模块回答“用户能在哪里点”。业务动作包回答“这件事能不能被带到结果”。

写在后面

AI Agent 进入企业软件，第一步未必是做一个万能 Agent。万能 Agent 听起来很完整。用户什么都能问，什么都能交给它，像一个懂业务、懂系统、懂数据、还能自己执行的虚拟员工。

但真实的 B 端产品通常不是这样长出来的。它更可能从一个小动作开始。一个菜单补全，一个活动测算，一个补贴复盘，一个异常派单。动作足够具体，边界足够清楚，结果能被验证，失败后能找回来。

跑通一个，再往旁边扩。这条路径看起来慢，但它更符合企业软件的现实。因为企业软件的价值不是“看起来智能”，而是“少一次交接，少一次返工，少一次错判”。

聊天框仍然会是入口。自然语言也会成为很多系统的新交互层。值得我们认真想的，是聊天框后面那一层：

• 哪些业务动作值得被 Agent 编排？

• 哪些动作必须保留人类确认？

• 哪些结果必须被系统复盘？

• 哪些失败必须提前设计兜底？

这些问题不如“做一个 AI Agent”听起来漂亮。但它们决定 Agent 能不能真的进入企业软件。Agent 进入企业软件，可能不是先替代一个系统。而是先替代一段来回倒手的业务动作。

参考来源

[1] The Ontology system, Palantir, 访问日期 2026-05-10, https://www.palantir.com/docs/foundry/architecture-center/ontology-system

[2] AI FDE Overview, Palantir, 访问日期 2026-05-10, https://www.palantir.com/docs/foundry/ai-fde/overview

[3] AIP, Foundry, and Apollo, Palantir, 访问日期 2026-05-10, https://www.palantir.com/docs/foundry/architecture-center/platforms

[4] Agent Skills, OpenAI Developers, 访问日期 2026-05-10, https://developers.openai.com/codex/skills

[5] Plugins, OpenAI Developers, 访问日期 2026-05-10, https://developers.openai.com/codex/plugins

[6] Extend Cursor with plugins, Cursor Team, 2026-02-17, https://cursor.com/blog/marketplace/

[7] Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, Gartner, 2025-06-25, https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

备注：文章配图使用 baoyu skills 生成