夜雨聆风先想一个很普通的企业场景。
过去，一个销售负责人想判断本周哪些订单有交付风险，可能要打开 CRM 看客户，打开 ERP 看订单，打开 WMS 看库存，再去 IM 里问供应链同事。
未来，他可能只对一个超级 Agent 说：
帮我看一下华东区本周哪些订单有交付风险，给我一个处理建议，并通知相关销售和供应链同事。
这句话背后的工作量没有消失。
CRM、ERP、WMS、报表、权限、审批、通知也都还在。
变化在于，用户不一定再从这些系统开始。
他先表达目标，再由 Agent 帮他选择工具、组织流程、调用应用、检查结果。
到了那一天，操作系统、超级 App、办公套件和模型平台，都会争夺同一个位置：
用户完成任务时的第一入口。
这对传统 ERP 厂商、行业 SaaS、垂直软件公司来说，是一个很微妙的变化。
它不一定意味着 ERP 明天就会消失，也不意味着每个行业软件都会被 ChatGPT、Copilot、Gemini、微信、飞书、钉钉直接替代。
更现实的危险是：
你还活着，但用户不再从你这里开始。
如果超级 Agent 能读取邮件、日程、表格、CRM、ERP、WMS、知识库和 IM，它就会先组织任务。
你的系统仍然存在。
你的数据库仍然重要。
你的接口仍然被调用。
但用户感知到的入口、上下文和解释权，已经转移到了超级 Agent 手里。
这才是行业软件公司真正需要警惕的地方。
不是被巨头正式进攻。
而是被超级入口顺手绕过。
所以这篇文章不想急着下一个“ERP 会不会被 AI 吃掉”的结论。
更值得讨论的是另一件事：
当超级 Agent 成为入口，行业软件怎样保留自己的专业位置？
或者说，它怎样从一个“被调用的系统”，变成一个“能承担任务的专业 Agent”？
这篇文章里的关系，可以先用一张图概括：
一、超级 Agent 拿走的不是功能，而是入口
很多人讨论超级 Agent 时，会先问一个问题：
它能不能把 ERP 做掉？
这个问题有点太粗。
ERP、MES、WMS、CRM、财务系统、医疗系统、教育系统、零售系统，背后都有复杂的数据结构、权限模型、流程状态、行业规则和审计要求。
这些东西不是一个通用聊天框靠几次工具调用就能完整替代的。
但超级 Agent 真正想拿走的，未必是所有后台功能。
它更想拿走四件事。
第一，任务理解权。
用户到底想干什么，以前是从系统页面和表单里体现出来的。现在用户可能直接把目标说给 Agent。
第二，上下文聚合权。
过去一个业务问题分散在邮件、表格、IM、文档和业务系统里。超级 Agent 的价值，就是把这些上下文拉到一起。
第三，工具选择权。
用户不再自己决定打开哪个系统、查哪个报表、点哪个按钮，而是让 Agent 判断应该调用哪个应用、哪个接口、哪个插件、哪个专业 Agent。
第四，结果解释权。
用户最后看到的，不一定是你系统里的原始页面，而是超级 Agent 整理后的摘要、建议和下一步动作。
这四件事一旦迁移，行业软件就会被重新定价。
过去软件争的是安装、账号、菜单、活跃和留存。
Agent 时代，软件争的是：
我是否会被选中调用？
我在什么任务里被调用？
我的结果是否被用户看到？
我的业务规则是否还能影响最终决策？
如果答案都是否定的，这个软件就会慢慢变成一个后台工具。
它不一定死。
但它会离用户越来越远。
二、行业软件的护城河还在，但不能只藏在 UI 里
行业软件公司当然还有价值。
甚至可以说，很多行业软件的价值在 Agent 时代会更重要。
因为真正的业务世界不是一句“帮我优化一下供应链”就能解决的。
一个订单能不能发货，要看库存、批次、账期、授信、交期、仓库容量、运输线路、客户等级、合同条款、促销计划和异常规则。
一笔费用能不能报销，要看预算、科目、发票、审批流、税务规则、项目归属和公司制度。
一个医疗建议能不能执行，要看病历、医嘱、药品禁忌、医保规则、医生权限和责任边界。
这些东西都不是通用 Agent 天然拥有的。
它们沉在行业软件里：
• 业务对象：订单、物料、批次、账期、客户、合同、工单、病历、课程、门店。 • 流程状态：申请、审核、执行、结算、归档、异常、撤销。 • 权限模型：谁能看，谁能改，谁能审批，谁承担责任。 • 业务规则：税务、库存、排产、风控、价格、合规、行业口径。 • 历史数据：多年沉淀的交易记录、异常处理和组织习惯。
这些仍然是护城河。
问题是，过去这些护城河大多藏在 UI、数据库、报表和接口后面。
人类用户通过页面理解它。
实施顾问通过配置解释它。
运维和开发通过接口维护它。
但当任务入口变成 Agent，行业软件只把能力藏在页面里就不够了。
如果超级 Agent 看不懂你的业务对象，找不到你的能力边界，不知道哪些动作可执行、哪些动作必须确认、哪些状态代表异常，它就很容易绕过你。
或者更糟：
它只把你当成一个普通 API。
API 能说明“我有一个接口”。
但 Agent 时代，企业真正需要的是：
你能不能承担一个任务？
三、行业 Agent App 要不要做？暂时没有定论
所以，行业软件公司是不是应该做一个行业 Agent App？
我的看法是：这个问题暂时没有标准答案。
不同公司会有不同选择。
有些行业软件有强用户入口，比如医生工作站、门店收银、生产现场、客服工作台、财务共享中心。这类产品可能确实需要自己的 Agent App，因为用户每天就在它的现场里工作。
有些系统主要是后台核心，比如结算、风控、库存、主数据、账务、计费。它们未必需要先做一个面向普通用户的聊天入口，但必须能被其他 Agent 安全调用。
还有些行业软件部署在客户私有环境里，受合规、网络和数据隔离影响，短期内不适合完全接入外部超级 Agent。它们可能更适合先做企业内部 Agent。
所以，先不要急着回答“我要不要做一个行业版 ChatGPT”。
这个问题容易把产品带偏。
行业软件公司真正该先回答的是另一个问题：
我的核心业务能力，能不能被 Agent 使用？
这件事的答案已经比较明确。
需要。
不一定先做 Agent App。
但一定要做 Agent 能力。
所谓 Agent 能力，不只是加一个问答框，也不是把帮助文档接进大模型。
它至少包括几件事：
• 能描述自己能做什么。 • 能暴露稳定的业务对象和输入输出。 • 能说明哪些动作需要用户确认。 • 能返回任务状态和结构化结果。 • 能处理异常、失败和权限不足。 • 能留下审计记录。 • 能被其他 Agent 发现、委托和协作。
这就是前一篇文章里说的 Agent Contract。
到了这一篇，还要再加一层：
行业软件不只要能被 Agent 调工具，还要准备好让自己成为一个专业 Agent。
这也是为什么 Salesforce、SAP、Oracle、ServiceNow、Workday 这些企业软件巨头，公开叙事里都没有把 Agent 简化成“给系统加一个聊天框”。
它们更强调的是角色上下文、业务流程、企业数据、Agent 编排和治理。
这个方向值得行业软件公司认真看。
因为企业 Agent 的本质不是会说话的 UI，而是被纳入流程和责任体系的执行单元。
四、A2A 的意义：从工具变成可协作的专业 Agent
过去我们常说 MCP。
MCP 解决的是 Agent 如何连接工具、数据和工作流。
它很重要。
但当任务变复杂后，仅仅“Agent 调工具”不够。
因为很多任务不是一个工具能完成的，而是需要多个 Agent 分工。
Google 推出的 A2A，也就是 Agent2Agent Protocol，关注的就是这个问题：
不同厂商、不同框架、不同平台上的 Agent，如何彼此发现、通信、委托任务、交换状态和交付结果。
这对行业软件公司很关键。
更准确地说，A2A 的价值不是让行业软件公司赶一个协议热点。
它真正提醒我们的是：
未来行业软件暴露给外部世界的，可能不只是 API 文档，而是一张 Agent 能力名片。
如果你只暴露 API，超级 Agent 看到的是一个工具。
如果你暴露一个 A2A Agent，它看到的是一个专业协作者。
这两者的战略位置完全不同。
工具是被动的。
别人决定什么时候调用你，怎么解释你，怎么组合你。
专业 Agent 是有边界的。
它可以说明自己是谁、能做什么、需要什么授权、能处理什么任务、任务进行到哪一步、交付物是什么、失败时怎么恢复。
A2A 里的 Agent Card 就很适合作为行业软件的能力名片。
它不是普通接口文档。
它更像一个数字员工的工牌：
我是谁。
我属于哪个系统。
我有哪些技能。
我能处理哪些任务。
我需要什么认证。
我会返回什么结果。
我有哪些限制。
所以，对行业软件来说，A2A 不是马上和所有平台互联的按钮。
更现实的价值是逼自己提前按 Agent 协作的方式重构能力边界。
未来超级 Agent 负责入口。
行业 Agent 负责专业任务。
A2A 负责让这些 Agent 彼此发现、委托和协作。
谁能先把自己的业务流程变成一个有身份、有边界、有审计的专业 Agent，谁就更不容易被超级入口顺手绕过。
五、行业 Agent 的边界：越懂业务，越要知道哪里不能自动化
这里还要特别强调一点：
行业 Agent 不是越自动越好。
越接近业务责任，越要有边界。
一个行业 Agent 可以查询、解释、对比和总结业务数据。
但它不能编造缺失数据，也不能绕过权限读数据。
它可以根据规则和历史案例给出建议。
但不能替代高责任岗位做最终判断。
它可以调用系统动作、发起流程、生成单据。
但不能无确认执行高风险、不可逆动作。
它可以通知相关人、收集反馈、推进待办。
但不能越权指挥其他部门或外部系统。
它可以发现流程瓶颈，建议规则调整。
但不能私自修改核心制度。
这听起来像限制。
但恰恰是行业软件公司的机会。
通用 Agent 最大的问题，不是它不会说，而是它不一定知道哪里不能做。
行业软件长期服务企业客户，最熟悉的不是“理想流程”，而是例外、权限、审批、留痕、合规和责任。
比如：
低风险、高频、可撤销的动作，可以更自动。
中风险、需要业务判断的动作，可以由 Agent 生成方案，人来确认。
高风险、不可逆、涉及资金、法律、人事、医疗、生产安全的动作，Agent 应该辅助，而不是成为最终责任主体。
跨部门、跨系统、跨公司协作，必须有授权、审计和升级机制。
这就是行业 Agent 的基本边界。
它的核心不是“更会聊天”，而是“更能负责”。
谁能承担业务后果，谁才有资格执行行业任务。
可以把这个边界简单整理成一张表：
六、超级 Agent 与行业 Agent 怎么协同？
未来更可能不是超级 Agent 和行业 Agent 二选一。
它们会分层。
超级 Agent 更像总助。
它离用户最近，理解自然语言目标，聚合跨域上下文，协调多个应用和 Agent，把结果解释给用户。
行业 Agent 更像部门专家。
它负责某个专业领域的业务闭环，理解对象、状态、规则、异常和责任边界。
企业治理层像制度和审计。
它负责身份、权限、审批、日志、成本、合规和风险控制。
举个例子。
用户对超级 Agent 说：
帮我判断这批门店下周是否会缺货，如果会，给我一个补货方案。
超级 Agent 先理解目标：这是一个供应链任务。
它不应该自己凭感觉分析，而应该找到供应链专业 Agent。
供应链 Agent 查询库存、在途、销量预测、促销计划、供应商交期和仓库容量。
如果补货方案涉及资金占用，它可以再通过 A2A 委托财务 Agent 评估预算和现金压力。
然后供应链 Agent 返回结构化结果：
哪些门店有缺货风险。
缺什么货。
预计什么时候断货。
建议补多少。
风险是什么。
哪些动作需要人工确认。
超级 Agent 再把这些结果翻译成管理者容易读懂的摘要。
用户确认后，专业 Agent 才在 ERP、WMS 或采购系统里创建建议单或审批流。
整个过程中，企业治理层记录：
谁发起了任务。
哪个 Agent 接管了任务。
读了哪些数据。
调用了哪些工具。
委托了哪些其他 Agent。
谁做了确认。
最终写回了什么。
这才是比较合理的协同关系。
超级 Agent 不必懂每个行业细节。
行业 Agent 不必抢所有用户入口。
企业治理层也不能缺席。
七、行业软件公司现在应该做什么？
如果把这件事落到产品和技术路线，我建议行业软件公司先做七件事。
第一，选一个高价值、闭环明确的任务。
不要从“全能行业大模型”开始。
先找一个高频、高痛点、数据可得、流程可控、有明确 ROI 的任务。
比如补货建议、应付对账、合同风险审查、售后工单分派、生产异常归因、门店经营诊断。
第二，把业务对象语义化。
订单、客户、物料、合同、发票、病历、课程、门店、工单，都要有稳定 schema。
Agent 不能只读文本，它要能读业务状态。
第三，把核心流程拆成 Agent Contract。
能做什么。
需要什么输入。
返回什么结果。
哪些动作需要确认。
失败时怎么恢复。
如何审计。
如果准备进入跨 Agent 协作，还要进一步思考 A2A 里的 Agent Card：
这个 Agent 是谁。
它能处理哪些任务。
需要什么认证和授权。
任务状态如何返回。
交付物如何表达。
第四，把权限、审批、审计前置。
Agent 不应该绕过原有治理体系。
它应该成为治理体系里的新执行主体。
第五，支持被外部 Agent 发现和委托。
可以是 MCP，可以是 Apps SDK，可以是 Copilot connector，也可以是 A2A。
具体技术路线会变，但方向很清楚：
不要只做给人点的功能，也要做给 Agent 调的能力。
第六，保留行业 UI。
不是所有场景都适合对话。
复杂审核、批量对比、异常处理、报表分析、责任确认，仍然需要可视化界面。
Agent 不是 UI 的替代品，而是任务入口和执行层的补充。
第七，建立 Agent 运营指标。
不要只看调用次数。
要看自动化率、人工确认率、错误率、撤销率、异常升级率、节省周期、业务结果改善。
Agent 能不能真正进入企业，不取决于演示多漂亮，而取决于能不能稳定改善业务结果。
八、哪些行业软件最容易被绕过？
最后，给一个判断清单。
最容易被超级 Agent 绕过的软件，通常有几个特征：
只做信息展示，不拥有核心交易流程。
只靠查询、导出、填报，没有写回和闭环。
数据结构混乱，业务语义只能靠人解释。
接口贫弱，Agent 很难发现和调用。
权限和审计薄弱，企业不敢授权自动执行。
业务流程高度标准化，又没有独特行业 Know-how。
产品价值主要来自 UI 操作习惯，而不是规则、数据和流程闭环。
如果一个软件只是“查一下、导一下、填一下”，超级 Agent 很容易绕过它。
但如果一个软件掌握“能不能做、怎么做、谁确认、出了事谁负责”，它就仍然有很强的位置。
不容易被吞噬的软件，也不是可以原地不动。
它们同样要 Agent 化。
只是它们的目标不是再做一个通用入口，而是把自己升级成专业任务的责任节点。
九、行业软件的下一张船票
超级 Agent 会继续变强。
它会越来越像任务入口。
但它不会天然懂每个行业的责任边界。
行业软件也不会消失。
但只给人点击的系统会变弱。
未来的软件可能会分成三层：
第一层是通用入口，也就是超级 Agent。
第二层是专业能力，也就是行业 Agent、企业 Agent、部门 Agent。
第三层是事实系统，也就是 ERP、CRM、WMS、HIS、财务核心、业务数据库和审计系统。
行业软件公司的任务，是从“页面供应商”升级为“行业能力供应商”。
更准确地说，是从“给人操作的软件”，升级为“能被 Agent 委托的专业责任系统”。
是否需要一个独立行业 Agent App，暂时可以不下结论。
但是否需要 Agent 能力，答案已经很明确。
需要。
而且越早按 A2A、Agent Contract、身份、权限、审计这些思路准备，越不容易被超级 Agent 顺手踩死。
但只要行业软件真的开始 Agent 化，企业很快会遇到下一个问题：
这么多 Agent，谁来登记、授权、路由、观测和熔断？
这就自然引出下一层基础设施：
Agent Gateway。
但那是下一篇要聊的主题。
超级 Agent 会决定用户先问谁。
行业 Agent 会决定任务能不能真正做完。
前者拥有入口。
后者拥有责任。
行业软件公司的下一张船票，就在这两个位置之间。
参考资料
• OpenAI《Introducing apps in ChatGPT and the new Apps SDK》
https://openai.com/index/introducing-apps-in-chatgpt/• Microsoft Copilot Studio
https://www.microsoft.com/en-us/microsoft-365-copilot/microsoft-copilot-studio• Salesforce Agentforce
https://www.salesforce.com/agentforce/• SAP Joule Assistants
https://www.sap.com/products/artificial-intelligence/ai-assistant.html• Oracle Fusion AI / Fusion Agentic Applications
https://www.oracle.com/applications/fusion-ai/• ServiceNow AI Agents
https://www.servicenow.com/products/ai-agents.html• Workday《Agent System of Record》
https://newsroom.workday.com/2025-02-11-The-Next-Generation-of-Workforce-Management-is-Here-Workday-Unveils-New-Agent-System-of-Record• Google Developers Blog《Announcing the Agent2Agent Protocol (A2A)》
https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/• A2A GitHub
https://github.com/a2aproject/A2A• A2A Specification
https://github.com/a2aproject/A2A/blob/main/docs/specification.md• Gartner《40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026》
https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025• Gartner《Over 40% of Agentic AI Projects Will Be Canceled by End of 2027》
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• McKinsey《Seizing the agentic AI advantage》
https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage• McKinsey《Building the foundations for agentic AI at scale》
https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/building-the-foundations-for-agentic-ai-at-scale
