★ FEATURED ARTICLE 过去半年我被问得最多的一个问题就是Agentic AI 会不会把传统软件公司逼到墙角一开始我以为这只是行业媒体的焦虑营销直到前阵子参加了几场线下交流听到了不少同行的真实遭遇才意识到这已经不是一个战略层面的宏大叙事而是摆在财务报表上的现实问题。这事对我来说很微妙。我做了快十年软件产品经历过传统套装软件时代也经历过SaaS转型如今又在帮几个老东家做AI相关的架构调整。站在一个“旧时代幸存者”的视角我既清楚传统软件公司的底气在哪里也看得见它们的软肋正一个一个暴露。这篇文章不打算做趋势预测我只想把最近观察到的冲击点、转型路径、具体的坑和可操作的步骤摊开来说给还在观望的公司做一个参考。1. 那场立项评审会之后我开始重新理解“卖软件”这件事1.1 当客户不再问“有哪些功能”而是问“能帮我办成什么事”事情要从一场客户立项评审会说起。那是一家做售后服务的公司准备上一套工单自动化系统。我们这边派出了销售、售前、交付三个部门的人准备了六十多页PPT从权限模型讲到报表中心把产品二十多个模块的功能讲得明明白白。方案报价按传统套路来软件授权加实施费总计两百多万。会上对方的CIO只问了一个问题“这套系统上线之后我原本负责工单分派和初步响应的十五个人能减到几个人”当时我们没办法回答。因为本质上我们卖的还是工具——工具再先进也要有人去操作。但同一场会上另一家做Agentic AI方案的公司给了完全不同的承诺系统上线后百分之八十的常规工单由AI代理直接处理处理不了的再转人工报价也改成了“按有效处理工单数付费”。客户当场就偏向了后一家。不是因为对方的模型多强而是因为他们把卖点从“功能清单”变成了“结果承诺”。这短短一个变化把整个商业逻辑的底层都换掉了——传统软件公司的位置从参与者变成了被比较的一方甚至是被绕开的一方。1.2 Agentic AI到底是什么一个“会自己干活”的数字员工很多朋友听到Agentic AI就紧张其实概念没有想象中那么玄。上一代的AI产品比如智能客服机器人、Copilot助手本质上是“辅助人干活的工具”用户提问它给参考用户写代码它给补全。它始终处在“人在回路里”这个位置。而Agentic AI的关键差异在于自主性。它不止能听懂指令还能把目标拆成步骤主动调用外部工具完成一系列操作并在出错时复盘调整。打个比方Copilot像一位坐在你旁边的资深顾问经验很丰富但拍板的永远是你Agentic AI则像一个能独立接活儿的实习生——你告诉它“把上个月的售后工单汇总分析一遍找出投诉率最高的产品线写一份结论给我顺手发给运营总监”它会自己去数据库取数、跑分析、写摘要、调通讯录发邮件中间遇到权限问题还会尝试申请或换条路处理。这个“目标的拆解、工具的调用、错误的纠正”三段式闭环就是Agentic AI的核心。它像一个装了无数“手脚”的大脑而传统软件系统中的API、数据表、工作流引擎恰好就是它可以借用的“手脚”。这件事的深意在于过去软件是“生产工具”人围着软件转现在Agent成了“劳动力”软件反过来要围着Agent转。传统软件公司如果认识不到这个身份的转换下一步就会发现自己越来越“不重要”。因为在客户眼里体系再庞大的软件系统也不过是Agent调用列表里的几个API而已。2. 利润发动机被逐台拆掉传统模式里最先失血的四个环节2.1 按席位收费的软件碰上了一个不需要休息的劳动力传统SaaS公司最舒服的商业模式就是按席位收费。客户公司有多少人事、客服、财务人员就买多少个账号每个账号按月付费。这套模型建立在“一个账号对应一个真实的人”的假设上Team里多一个人就要多一份钱所以客户规模越大软件公司收入越高。但Agentic AI一进来这个等式直接被打破。一个Agent不是一个人力它可以同时开几十个并行会话7乘24小时在线不需要年假、不会离职、不需要工位和社保。我见过一家客服软件的老客户原来买了两百个坐席账号引入Agent后直接把账号砍到二十个剩下的人工只处理那些Agent搞不定的复杂投诉。这对软件公司来说是非常直接的收入坍缩。更麻烦的是如果Agent方案是按效果计费比如处理一个工单收一块钱那么客户完全可以让AI代理来处理大部分会话然后再把剩下的少量工单交给人。同样是软件提供方收入从“稳定留存的大盘子”变成了“按量付费的碎片账单”这是两种商业模式之间的巨大落差。2.2 定制开发项目制交付速度越快团队越尴尬传统软件公司另一块收入大头来自定制化开发和实施交付。客户总有一些“特殊需求”字段要多一个流程要拐个弯报表要换个口径。厂商于是拉一支项目组做需求调研、写开发文档、排期开发、联调测试最后按人天报价。这套模式在过去几十年里跑得很顺畅原因是它把“不确定性的人力成本”嫁给了客户需求复杂想不清楚没关系多个层次就多收你几十万。然而Agentic AI出现之后客户对定制化的容忍度变了。他们发现与其花几百万让软件公司花半年时间做一个“很重的定制模块”不如用一个能自主学习、灵活调整配置的Agent在几周内把流程跑起来。一位做交付的朋友最近吐槽原本要卖三百人天的接口改造项目客户把需求文档丢进了某个大模型工具里让AI代理读文档、生成映射关系、自动写转换脚本结果一周就出活。虽然后续的质量和运维还有问题但客户已经不那么依赖“人力堆砌式交付”了。定制开发这口饭吃一次少一次。2.3 靠人力堆出来的护城河现在反过来了传统软件公司的护城河里有一条很显眼我有庞大的实施团队、客服团队、二次开发团队客户服务响应快出了问题能兜住。这套“人力规模优势”在过去确实是壁垒——客户担心小厂商服务跟不上所以更愿意选择人员充足的成熟厂商。但今天这个壁垒正在反向变成负担。因为Agentic AI让竞争对手可以用极小的团队提供同样甚至更快的交付能力。你有一支两百人的服务团队对方只有十个人加三个Agent响应速度和服务覆盖半径却比你大得多——这在过去几乎不可想象。而组织庞大带来的薪酬、管理、办公、差旅成本全部摊在利润表上随着老客户流失和单价下降压力会越来越大。2.4 渠道伙伴体系中间商赚差价的链条正在变细还有一个常被忽视但失血很快的环节就是渠道生态。传统软件公司非常依赖区域代理、行业伙伴去拓展中小客户分30%到50%的利润出去。这个链条之所以存在是因为软件本身需要“人肉触达”客户需要销售讲故事、做评估、推实施。Agent化产品和服务不一样。它的体验入口往往是一个网络聊天界面、一个API或者一个自动化的嵌入组件。客户在官网上传一份需求Agent配置就能生成试用版本不需要销售反复做Demo。于是很多原本属于渠道伙伴的活被产品体验本身取代了。代理商的价值变薄愿意推你产品的渠道商越来越少而对渠道伙伴的返佣政策做得越重的公司调整起来伤筋动骨。3. 真正能活下来的公司正在完成三种角色切换讲完失血点再讲活法。我观察下来目前能够重新站住脚的转型企业基本都是在往三个方向上做切换。这三种角色不是互相排斥的有的公司也能同时做两三种但最好一开始只选一个主方向集中打透。3.1 活法一让Agent离不开你的数据与工作流底座第一种转型方向是不跟Agent直接抢“对话入口”而是退到更底层的“基础设施”位置——把自己的软件改造成一套Agent友好、可被调用的工作流底座。我见过一家做库存管理系统的公司他们的老产品有一套很完善的库存查询、调拨、盘点、预警机制。过去客户买回去还是靠人来操作界面。转型之后他们把核心业务能力全部接口化做成了一个个原子化的API工具并且开放了完整的调用记录和权限控制。然后他们去找Agent方案商合作不管客户用的是哪家大模型驱动的Agent只要涉及“查库存”“创建调拨单”“触发补货预警”这类动作都通过他们的API完成。这样一来客户虽然面向的是某个Agent的聊天界面但背后真正干活的引擎还是这家公司的系统。它的收入模式从按License收费变成了按API调用量加服务等级协议订阅。本质上是把自己从“给用户用的软件”变成了“给Agent用的工具集”。这个方向的关键在于两点一是产品底层必须有干净的数据模型和完整的API设计不能嘴上说开放实际还是要靠人操作界面二是要敢把积累多年的业务规则沉淀成可调用的服务——这一步很多公司舍不得做因为它们习惯了把流程封装在产品内部做成黑盒卖给客户。但Agent时代透明和可组合才是信任的基础。3.2 活法二从卖软件许可证变成卖“办成率”第二种方向是最刺激也最考验决心的不卖软件卖结果。把自己的产品彻底重写成一个Agent优先的服务型产品按“任务完成效果”向客户收费。客户不再关心你的系统里有几个模块只关心你的Agent能不能把工单处理好、把账算明白、把客户投诉安抚下来。具体到落地就是把原来产品的能力拆成两个部分一部分是Agent自主执行的自动流程另一部分是人工兜底的运营团队。客户表面上是采购了一个Agent服务实际上得到的是一个“95%自动化加5%人工保障”的服务团队。比如做帮助台软件的公司可以转型做“帮客户处理全量工单”的服务按工单解决率和平均响应时效计费。做财务软件的公司可以转型做“代理公司处理对账、开票、催款”的服务。这个方向对公司的组织能力要求很高因为它是从“交付一次项目”变成了“持续运营一个服务”。利润率不再取决于软件销售定价而取决于你调教Agent的效率、人工兜底的成本、以及客户续约率。它会倒逼公司建立一套以前没有的能力效果指标体系、反馈闭环、持续优化机制。但反过来这套能力一旦建立起来客户的替换成本会非常高——买软件可以随便换但把一个核心业务流程外包给一个持续运营的Agent服务之后很少有人愿意轻易搬走。3.3 活法三不碰Agent也能靠Agent生态养家第三种方向适合那些不想冒太大风险、也不太擅长做AI模型应用的公司。不直接做Agent转做Agent生态里的“卖水人”。任何一家正规企业要落地Agent都需要一系列配套能力如何评估一个Agent好不好用如何对海量Agent调用做监控和审计如何在不同Agent之间做统一的安全沙箱如何给Agent准备高质量、有版权的数据集这些需求都是实打实的而传统软件公司恰好擅长“做标准、做工具、做服务”。举个例子做软件测试业务的公司完全可以开发一套专门针对Agent的评测平台让客户上传任务场景自动生成一批评测集然后跑效果对比报告。做数据治理的公司可以把积攒多年的数据清洗和质检能力封装成Agent可调用的工具。哪怕只是做一家“Agent训练数据标注服务提供商”现在都有不小的市场。这个方向的好处是能直接吃到Agent行业的增量红利又不需要自己掌握大模型的核心研发能力。缺点是把鸡蛋放在了别人的篮子里——你的生意好坏很大程度取决于Agent市场的整体热度。但我一直觉得传统软件公司最强的资产不是代码而是在某个垂直行业里积累了多年的业务理解和客户关系。这些东西在Agent时代依然值钱关键是找到把它们“产品化”的新姿势。4. 从零改造一个Agent产品时我最想让你避开的六个细节4.1 先选好第一枪不是所有场景都适合做Agent化很多团队一上来就想做一个“通用企业智能体”什么活都能干。这是最典型的失败开局。Agent化改造的第一个成功要素是选对场景。我一般会给团队一个筛选标准满足下面几条的优先做场景高频、重复性强规则相对清晰比如工单分派、发票录入、库存盘点有明确的“任务成功”标准比如工单被正确解决对账差异被消除能形成数据闭环每一步操作都有日志和结果可追踪失败的影响范围可控不会因为一次误操作造成客户流失或者安全事故。打个比方你想给公司推“自动化助手”优先选一个“验票放行”这样边界清楚的事情而不是上来就做“全流程门禁总控”。第一枪打一个小而准的场景跑通了再逐步扩展边界比一开始就摊大饼靠谱得多——我现在给自己团队定的规矩就是“先赢一局再谈系统”。4.2 把工具接口做成Agent能用的“手和脚”Agent本身是个聪明的大脑但它需要依靠外部工具才能干活。如果你的系统连一个好的API都没有那Agent再怎么强也只能“光说不练”。我见过不少改造失败的例子本质都出在工具层API字段字段含义含糊、缺少幂等设计、没有调用上限和降级机制。这里有几个实操建议第一API设计要做到原子化——一个接口只干一件事查询就是查询创建就是创建不要塞进一堆隐式逻辑第二接口必须幂等——同一个请求重复调用十次效果跟调用一次一致这是Agent重试机制的基本保障第三要有完整的调用审计记录每次请求的参数、结果、耗时和发起者。否则Agent在内部循环里反复调用出错接口时你连问题在哪都找不到。工具层还有一个容易被忽略的点要为Agent准备“失败信息”。传统接口出错时返回一个错误码给前端就够了但Agent会自己“阅读”错误信息并决定下一步。如果你接口报错时只弹一个“系统异常”Agent会陷入无法自救的死循环。更好的做法是返回结构化且可行动的提示比如“参数XX超过了上限允许范围是0到100”这样的信息对Agent的自主纠错非常关键。4.3 数据与反馈Agent的成长完全取决于这一环很多人以为Agent效果好坏主要看模型选得好不好其实在真实项目中决定上限的是数据和反馈闭环。Agent每执行一个任务都会产生调用记录、中间结果、最终产出。这些数据如果不被收集、标注、复盘那Agent永远学不到东西。我们做客服Agent改造时专门搭了一套反馈机制Agent处理完一个工单之后客户如果点了“不满意”这条记录会进入后台人工复核池人工修改了Agent的答案后修改前后的内容会作为新的训练样本沉淀下来。这个过程很像“带徒弟”——师傅人工纠正一次徒弟Agent就能记住一次。没有这个闭环Agent就是一个永远考不及格的学生。另外要提醒一点Agent的数据标注比传统机器学习更复杂因为它的中间步骤很多。你不仅要标注“最终答案对不对”还要标注“中间选用了哪条工具路径、哪一步导致了偏差”。这需要领域专家深度参与不能只靠标注员按模板打标签。这也是传统软件公司在组织能力上需要重点补的一课。4.4 团队有一个算一个别照搬互联网大厂配置传统软件公司做Agent改造最容易犯的用人错误就是“招一堆提示工程师像招外包文案一样用”。提示词确实重要但Agent应用的核心能力远不止写提示词。我建议按三类角色搭建最小团队LLM应用工程师负责Agent的编排、工具调用、上下文管理、异常处理。这类人要有工程思维能把一个复杂任务拆成可靠的代码逻辑而不是只会问“AI能不能帮我写段文案”。领域专家不一定写代码但必须懂业务流程和行业禁忌。他们的任务是告诉Agent哪些动作绝对不能做、哪些步骤必须留痕、哪些话术容易引发合规风险。平台工程师负责SLA、限流、降级、可观测性、权限管理。Agent运行起来之后稳定性问题会比功能问题更早暴露没有平台层支撑Demo做得再漂亮也会在线上一夜翻车。团队规模不一定要大我见过十个人左右的精锐小队把一个售后工单Agent做到了不错的效果也见过五十个人的“AI创新中心”半年没跑通一个闭环原因就是角色混在一起人人都在搞所谓“创新”没人管工具链和数据质量。麻雀虽小五脏得俱全。4.5 成本算清楚钱花在哪、怎么定价、怎么控损Agent改造不是一次性投入而是持续运营成本。我按当前主流大模型的市场行情给一个粗略的单任务成本拆解方便你对账成本项典型构成占比大模型推理费用主任务多次调用包含规划和重试50%~60%向量检索与知识库查询每次查询相似文档需embedding和检索15%~20%工具调用与外部API费用查库存、发通知、更新记录15%~20%人工兜底与复核成本低置信度转人工、定期抽检10%~15%这里最容易被低估的是“多轮推理”的token消耗。一个Agent完成一次复杂工单可能要调用模型五六次甚至更多——最初规划一次中途发现错误重试一次最后总结一次。单次看起来便宜乘上任务量就非常可观。所以成本控制上有三件事值得做一是给单任务设置“最大轮次”上限防止Agent在同一个问题上反复横跳二是能用一个API工具完成的操作不要让模型自由发挥绕远路三是按场景单独做成本监控看板哪些场景单任务成本居高不下要能第一时间看到。定价模式也要跟着改。如果你的Agent能够替代客户原本三个人干十个小时的活那就不要按人天报价试着按“处理成功一个任务”收一个固定费用或者按月订阅并把价值与效果指标绑定。客户更容易接受“效果付费”的模式这对销售推进也是一个很好的卖点。4.6 安全边界给Agent上一层你睡得着的保险Agent自主行动能力越强安全风险就越大。很多团队在Demo阶段不会碰到安全问题因为都是模拟数据、测试环境。一旦上了生产环境遇到真实交易、真实客户投诉、真实企业通讯录一个小的权限漏洞就可能导致不可收拾的后果。我给自己项目定的安全基线如下线上Agent使用独立账号和最小权限只能访问完成任务必需的数据范围所有对外操作比如发送邮件、创建订单、修改财务数据默认需要“敏感操作二次确认”除非业务上特别要求全自动Agent每一步操作落审计日志确保事后能完整回放系统设置“熔断开关”监控到异常指标变化时自动暂停Agent运行转由人工接管。这些机制看起来会削弱Agent的“自动化纯度”但实际交付中客户反而更放心。因为企业级采购最看重的不是“全自动”而是“可控的全自动”。你先把保险系上才有资格跟客户谈效率提升。5. 五块暗礁我亲眼见过的一些翻车现场与应对思路5.1 暗礁一半吊子Agent——对话很聪明办事总翻车有些公司转型心急把产品界面上接一个能聊天的Agent入口就说自己是“AI赋能的下一代产品”。结果用户进去一问Agent回答得头头是道但让它实际改一个订单状态、触发一个审批流、生成一份合规报表它就各种出错或推诿。这种“半吊子Agent”比没有Agent更伤害品牌。我见过一家公司上线这种半吊子产品之后客户试用群里一周之内涌进来几百条负面反馈最后只能紧急下线。原因就是他们把Agent只做成了“会说话的搜索引擎”没有真正打通背后的业务系统。要避开这个坑我的建议是不要在没有完成工具接口化和数据底座之前贸然把Agent推到客户面前。宁可初始功能少一点也要保证能做成的任务做得干净利落。5.2 暗礁二责任断链——出了错谁为Agent的行为负责Agent开始自主决策之后最让人头疼的就是责任归属问题。传统软件出错责任边界还能划清楚是程序逻辑有Bug还是使用人员操作不当。但Agent的决策过程是一条复杂的推理链它在哪个环节被误导、为什么做了某个选择往往不那么容易定位。更麻烦的是过去我们把操作记录看成软件的辅助数据Agent时代却必须把它当成核心审计资产来看待。每次Agent的决策依据、调用过的上下文、读过的数据都要完整留存。不要等问题发生之后再去翻日志那多半已经来不及了。企业客户跟我们签约时也会特别关注“AI行为审计”这一章节——这正是新的合同风险点也是新的机会点。5.3 暗礁三信任赤字——模型越自信客户越心慌大模型的通病是“答错的时候也格外自信”。同一个Agent前面三单处理得完美第四单给客户报错了库存数据语气依然笃定。这种不可预测性会让客户慢慢流失对系统的信任。实际项目里我倾向于给Agent增加一个“自我评分”机制每个任务完成之后Agent基于置信度输出一个分数低于一定阈值的善意转人工处理。哪怕增加了一些人工成本也比让客户收到一个错误结论要好。另外所有面向客户的答复应该尽量附上“信息来源”和“执行依据”透明化能有效缓解黑箱恐惧。信任这种东西建立起来要很久崩塌往往只要一次错误报告。5.4 暗礁四成本黑洞——效率提升是真的账单爆炸也是真的前面提到成本模型时我留了一句话真正的成本黑洞往往出现在“看似便宜的叠加”上。很多团队先算了一笔账觉得模型调用费不高就放开让Agent折腾。结果Agent在复杂的业务场景里频繁重试、连环调用外部工具月底账单出来吓一跳。我有一次排查某个Agent项目费用超标发现它为了完成一个“查询客户历史订单”的任务竟然反复搜索了二十多次知识库原因是最初的查询请求写得太宽泛。最后解决方案很简单给工具调用加“去重缓存”和“上下文压缩”让同样的信息只查一次。成本控制不是事后追责而是要在工具层就做好约束。5.5 暗礁五组织惯性——船太大船头就是转不过来最后一块暗礁不在技术上而在组织上。传统软件公司的考核体系、销售激励、研发节奏全部是为“卖软件许可证”设计的。销售习惯了卖高单价、长周期的License很难接受卖“按月效果订阅”研发习惯了按版本迭代很难适应“持续优化一个Agent服务”的节奏管理层担心新业务吃掉老产品收入迟迟不敢大力投入。我见过一家企业专门成立了一个Agent转型团队结果考核指标还是按老业务线来定——新团队做的所有东西都要跟传统产品线抢预算、抢客户最后不到一年就归零了。要想让转型活下来我觉得至少要给新业务设一个独立的预算池和独立的汇报线至少在成长期内别让它跟老产品直接竞争。组织上的隔离是技术落地之外最重要的一道保障。最后说点个人的体会。我刚开始把一个知识库接到Agent上的时候第一周效果烂到我自己都不想看总是答非所问动不动就转人工。但我坚持把调用记录、人工修正结果、用户反馈三个数据源全部打通每天盯着一张效果曲线调整提示词和工具编排到第二周任务成功率就明显回升。转型这件事也一样前一个月肯定是灰头土脸的数据闭环跑通之后后面是复利。别急着把一切推倒重来先拿一个小场景证明自己能赢再谈扩大战场。Agentic AI这波浪潮确实在考验传统软件公司的生存能力但它同时给每个愿意放下身段、重新设计产品和商业模式的人留了一张门票。能不能拿到看的不是预算多不多而是你愿不愿意先从客户真正在乎的结果出发。
阅读完成 · 觉得有帮助？
