ARTICLE · 1295343
封闭:国内软件在AI时代的死穴
当AI开始替你使用软件
国内的软件，在AI时代，会不会被自己的“封闭”困住？
为什么现在谈这个？因为AI正在发生一个关键的变化。以前，它主要帮你回答问题；现在，它开始替你把事情办完。你把一件事交给AI Agent，也就是我们常说的智能体，它自己去找工具、去操作软件，最后把结果交回给你。
问题随之而来：过去是人在各个软件之间来回切换，现在换成AI来干这个活，它能不能顺利接得住？
这不光是手机App的事，办公软件、企业里的各种业务系统，其实都绕不开。 这背后有技术问题，有安全问题，也有商业上的算盘。
先不急着讲大道理，从一个具体的例子说起：豆包手机助手。
从豆包手机上，我们看到了什么？
2025年底，豆包手机助手引起过一轮热闹的讨论。
它想做的事情说起来很简单：把AI助手放到手机系统这一层，让它不光能回答问题，还能直接帮你操作手机上的App。
比如你跟它说，帮我看看朋友发的消息，帮我查个商品，帮我找份文件，它就自己去点、去找、去办。 这其实是很顺理成章的一步。AI已经能看懂屏幕上的内容，也能模拟点击、输入文字，那它为什么不能像人一样用手机呢？
可问题恰恰出在这儿。手机上的软件，从来就不是一个统一的世界。
每个App都有自己的规矩：有的操作能做，有的一做就触发风控；有的必须本人确认，有的干脆限制自动化；还有的，压根不允许第三方AI用模拟点击的方式来操作。
所以，2025年底，豆包手机助手出过操作微信异常的问题；后来，它又下线了银行和互联网支付类应用的操作能力。
到了2026年9月，豆包开始推一套“应用声明”机制，让第三方应用自己说清楚：哪些界面允许AI自动操作，哪些不允许，再配上用户授权和操作审计，来解决安全问题。
有个地方需要讲清楚，免得误会。这不等于所有App都联合起来在挡AI，也不能说所有限制都是为了护住自家生意。
银行限制自动操作，很可能是为了资金安全；支付要本人确认，是因为一旦出错，责任得说得清；微信这类应用限制某些自动化，也可能出于账号安全、隐私保护和反欺诈的考虑。这些理由本身都站得住。
所以，不能把这件事简单理解成：AI来了，软件公司不高兴，于是把AI拦在门外。
但豆包手机这件事，确实让我们看见了一个以前很少有人注意到的现象。
你自己用手机时，感觉不到这些边界，因为你是个人。打开微信看完消息，切到淘宝找商品，再切到支付软件付钱；身份验证、点确认、填信息，按每个App的规矩一步步来，这再平常不过。
可一旦想让AI替你干这些，问题就冒出来了：AI可能已经知道你想干什么，技术上也有能力去操作屏幕，但它未必有这个权限，也未必有一条稳定的、官方认可的路，能把事情办完。
于是出现了一个奇怪的局面：AI在技术上明明已经能做到的事，最后却卡在了软件和软件之间的边界上。 打个比方。
你雇了一个特别能干的助理，能看文件、能查资料、能用电脑，你说什么他都听得懂。你让他去帮你办件事。
第一家店说：价格你可以看，但不能替你老板下单。
第二家店说：单可以下，但必须你老板本人来操作。
第三家店说：你得先下载我们的App，注册个账号，所有步骤都在我们这儿完成。
转了一圈，助理回来说：老板，事儿我都摸清楚了，但真要办完，还得您亲自来。
这是不是听着有点耳熟？
我们早就习惯了这样的数字生活：每个软件都有自己的账号、自己的数据、自己的规则。在一个平台攒下的东西，很难完整搬到另一个平台；在这个App里办了一半的事，换到那个App，往往还得从头来。
以前，我们没觉得这有多严重。软件本来就是给人用的，人记得住密码，看得懂规则，切换界面也不嫌麻烦。麻烦是麻烦，但一直都这么过来了。
现在AI要来接手这些活儿，那些早已习以为常的边界，一下子变成了真正的问题。
当然，豆包手机只是一个案例，也不是说所有自动化操作都应该被放行。
但它像一个切口，让我们看到国内软件生态里一个更普遍的状态，也抛出了一个值得琢磨的问题：当用户开始把事情交给AI，软件公司到底愿不愿意让AI用自己的能力？ 软件公司为什么会犹豫？要回答这个问题，就得看看它们到底靠什么赚钱。
过去软件商业模式，正在发生变化
退一步看看过去二十年，互联网公司是怎么赚钱的。 很多软件公司，其实不是单纯靠“功能”赚钱，而是靠围绕“入口”搭起来的一整套生意。
举个最简单的例子：买鞋。
你打开一个电商平台，搜“鞋”，跳出一大堆商品，开始比价格、看评价、看销量。但你看到的，不一定是全市场最适合你的那几双。平台会按自己的规则排序，中间还夹着广告和推荐。最后你挑了一双，下单。
站在你的角度，这只是一次普通的购物；站在平台的角度，处处都是生意：商家想排得靠前，就得买广告；想多卖点，就得交佣金和服务费；平台再根据你的浏览和购买记录，推荐得更准，转化得更好。
所以，平台不只是给买家和卖家提供了一个见面的地方，它还掌握着商品怎么被你看到、你怎么做决定、最后在哪儿成交。
而这一切有个前提：你得先走进它的平台。 再看内容平台。你打开短视频App，本来只想看一个，结果刷完一个又来一个，原本打算看五分钟，一抬头半小时过去了。
平台靠推荐算法把你留下来，再靠广告和其他业务变现。这里面最值钱的，不只是视频本身，而是你的注意力。你待得越久，它就越有机会给你看内容、看广告、推服务。
所以，传统互联网公司最在意的其实就三件事：用户从哪儿进来，进来之后干什么，最后在哪儿成交。
入口、过程、交易，三环一扣，就是我们今天熟悉的互联网商业模式。
而AI Agent，恰恰可能把这根链条拆开。还是说买鞋。
以前，是你自己打开电商平台，自己搜、自己比、自己看评价、自己拿主意。
现在，你可以直接跟AI说：我想买一双每天通勤穿的鞋，预算500元左右，要舒服、耐穿、别太重，帮我比比几个牌子，看看评价里有没有质量问题，最后推荐一双。
如果Agent能拿到足够多的商品信息，大部分筛选工作它就替你干了。你愿意的话，还可以授权它：符合条件就直接下单。这时候，你还需要打开某个电商平台吗？
可能要，也可能根本不用。你关心的是鞋合不合脚、价格划不划算、什么时候能到；至于它来自哪个平台，好像没那么重要了。
这意味着，原来攥在电商平台手里的入口，有一部分被Agent拿走了；原来由平台组织的比价过程，被Agent接管了；原来要你自己一下一下点的那些步骤，也被Agent省掉了。
对用户来说，这当然是好事，终于可以摆脱那些重复、琐碎、没什么价值的操作。可对软件公司来说，事情没那么简单：
用户不打开我的App，我的广告给谁看？ Agent在好几个平台之间直接比价，我的推荐排序还有多大用？ 用户不用我的搜索框了，商品怎么被发现，还归我管吗？ 用户让Agent直接下单，我的交易入口会不会被架空？
这些问题不是哪一家公司的烦恼，而是整个互联网行业都可能撞上的墙。当然，这并不是说Agent会彻底取代App。
大家还是会刷视频、打游戏、在社交软件里跟朋友聊天，很多事本来就需要一个界面，需要人亲自参与。 更现实的情况可能是：一部分事情，人还是自己用App来做；另一部分，会慢慢交给Agent。而偏偏是这些被交出去的事情，过去恰恰是很多平台用来组织流量、推荐和交易的地方。
所以真正值得关心的，不是App会不会消失，而是：当越来越多的事情交给Agent去办，软件公司原来赖以赚钱的那些环节，还有多少能攥在自己手里？
想明白这一点，就能理解为什么很多软件公司在AI这件事上，会做出一种看起来很积极、底层却很保守的选择。
软件公司最大的壁垒，不是没有AI，而是只给自己的软件加AI
什么选择？AI要做，但只在自己家里做，不让外人的AI做。
今天几乎每家软件公司都在搞AI：有的加了AI搜索，有的上了AI客服，有的做智能推荐，有的让你一句话生成内容，还有的直接在App里塞了一个聊天机器人。这些功能当然有用。 但这里得分清两种完全不同的变化。
第一种，是让原来的软件变得更聪明；
第二种，是让AI能跨过不同的软件，把它们的能力组合起来，替你办完一件完整的事。
听上去都叫“AI化”，其实根本不是一回事。
拿办公软件举例。一个办公软件加了AI，能帮你写会议纪要、总结文档、生成表格，挺方便。但如果你真想办成一件事，比如准备一场部门会议，要做的就多了：找相关文件、确认谁来参会、看大家什么时候有空、约时间、建文档、发通知，最后还得把会上的任务分给相应的人。
如果这个AI只能待在一个办公软件里，它能帮你的也就是其中一小段。可如果它在你授权之后，能调用日历、通讯录、文档、任务管理这些系统的能力，就有机会把整件事从头串到尾。 差别在哪儿？
前一种，是软件公司把自己的产品做得更好用；
后一种，是软件公司把自己的能力，变成别的Agent也能用的服务。 这意味着，软件竞争的玩法在变。以前比的是：谁的功能多、谁的界面好、谁的用户多。以后可能还得比另外几样：谁的能力更容易被Agent找到？谁的接口更稳？谁的权限规则更清楚？谁的服务能跟别的系统顺畅地拼在一起？谁能真正帮Agent把事情办完？
作为普通用户，你可能不在乎这些技术细节，只会感觉到：有的AI助手能把事办完，有的只会告诉你该怎么做；有的能自动整理资料、约会议、更新任务，有的每走一步都让你自己去开一个App；有的一口气走完整个流程，有的最后甩给你一堆链接，剩下的自己看着办。
这些差别，一开始是体验上的差别，往后就可能变成软件公司之间的竞争差距。
这两种做法，有时看起来挺像，背后的商业逻辑却完全不同。到了AI时代，这个区别会越来越要紧，因为用户最终在乎的，不是某家公司想在数字世界里占个什么位置，而是：我交给AI的事，它到底能不能替我办完？ 如果一家软件公司愿意让AI在安全的前提下使用自己的能力，它就有机会成为Agent生态里的一块拼图。
如果它只想让用户继续打开自己的App，却不愿让外部Agent碰自己的核心能力，那它迟早得面对一个问题：当用户不再需要亲自打开App的时候，你还能靠什么继续给用户提供价值？ 接下来，具体看看国内的软件公司现在站在什么位置。
国内软件，到底有多封闭？
先看看国内软件已经开放了哪些能力，再分析不同公司为什么会做出不同选择。
国内软件，也有在开放的
比如钉钉。很多人对钉钉的印象，可能还是一个办公软件，用来发消息、开会、走审批、管理任务。但如果去看钉钉开放平台，会发现它已经开始把不少办公能力提供给Agent调用：消息、文档、通讯录、日历、待办，还有AI表格。
钉钉在同时做两件事。
一是让AI智能体使用钉钉：用户可以在钉钉内部使用AI，也可以让其他Agent来操作钉钉的办公能力。
二是让钉钉连接外部智能体：用户使用其他Agent，也能在授权条件下调用钉钉提供的部分能力，再通过接口直接调用相应的业务能力。
对软件来说，这是一个很大的变化：原来主要是把功能做给人用，现在还要考虑怎么把这些功能提供给AI使用。
飞书也是类似的情况。飞书本来就有比较丰富的开放平台，文档、通讯录、消息、日历等都有相应的API。
随着Agent的发展，这些原本主要服务于开发者和企业集成的接口有了新的用途：原来，企业需要专门开发一套系统，把飞书和其他业务系统连接起来；如今，Agent可以在适当授权下调用这些工具，完成一部分原来需要人工操作的工作。
这说明，国内企业软件并不是只能把AI关在自己的应用里面，它们也在尝试让AI直接使用自己的业务能力。
还有支付宝，已经开始建设面向Agent的支付和服务计费体系。它探索的方向，是让Agent在用户授权的前提下发起购买、完成支付确认、获取订单结果；同时，一些数字服务也可以通过API或Skill按调用量收费。
这一变化更值得关注。过去，支付平台主要服务于人和商家之间的交易。如果Agent开始替用户购物、预订服务、购买数字产品，Agent本身也会成为交易链条中的重要参与者。支付宝如果能把授权、支付、结果回传这些环节做得足够可靠，就有机会成为Agent经济里的基础设施。
当然，不能把产品发布直接等同于商业成功。有了接口，不代表已经有大量Agent在使用；有了支付方案，也不代表已经形成了大规模交易，还要看实际的接入数量、交易规模和用户使用情况。
但至少，这些案例说明国内已经有企业开始思考：如果未来的用户不再亲自操作每一个软件，软件公司能不能通过开放自己的能力，继续参与用户的任务和交易？
接下来要追问一个更关键的问题：为什么有些企业愿意开放能力，有些却特别谨慎？这里面的差异，比有没有API更重要。
同样是软件，为什么有的愿意开放，有的不愿意？
这就得往商业模式里再走一步。
同样是软件公司，为什么有的已经开始把能力开放给外部Agent，有的却比较谨慎，甚至主动限制外部AI访问？
这当然有技术、安全和合规方面的原因，但只从技术角度理解还不够。更深层的原因，是不同软件公司在产业链里赚钱的方式不一样，而Agent的出现，可能会改变它们原来的赚钱方式。
可以先做一个粗略的区分：一类软件公司，主要通过提供某种能力赚钱；另一类，除了提供能力，还非常依赖掌握用户入口来赚钱。现实中，绝大多数软件公司两种生意都做，这个划分只是帮助我们看清，它们面对Agent时为什么会有不同的考虑。
先说第一类，比如云服务、模型服务，以及一部分企业软件。买云服务，是为了获得计算能力；调用模型，是为了获得推理和生成能力；使用企业软件，是为了完成协作、管理或某项业务流程。
这些产品也有自己的界面，也需要销售、品牌和客户关系，但它们提供的能力本身就可以成为商品。只要服务质量可靠、接口设计合理、权限管理得当，不管是人直接使用，还是Agent代替人调用，都可能创造价值。对这类公司来说，外部Agent确实可能成为一种新的销售渠道。
如果Agent能够发现一项服务，理解它能做什么，并在获得授权后调用它，这项服务就有机会进入更多工作流程。原来不知道这项服务的用户，可能通过Agent第一次使用它；原来需要人工操作的业务，也可能因为Agent能调用这项服务而更容易自动化。
但也不能因此认为，这些公司会心甘情愿地把自己变成Agent背后的一个工具。如果用户越来越少地直接接触一家软件公司的产品，全部通过某个Agent使用它的能力，那么用户还知道这家公司叫什么吗？还会主动选择它吗？它又怎么了解用户真正的需求？
过去，用户打开软件的控制台、使用各种功能、遇到问题联系客户支持，这些过程不只是产品交互，也是公司了解客户、改进产品、建立品牌和维护客户关系的渠道。 如果这些交互都转移到了外部Agent那里，底层软件公司看到的，可能只剩下一次次接口调用。它知道有人用了自己的服务，却未必知道用户为什么需要；知道某次任务失败了，却未必掌握整个任务的上下文；甚至不知道下一次选择它的，还是同一个客户，还是Agent临时从其他供应商那里切换过来的用户。
所以，开放能力确实能带来新客户，但也可能让软件公司失去一部分直接了解客户的机会。
对这类公司来说，真正危险的，不是成为Agent能够调用的服务，而是自己的服务越来越容易被替换，客户却越来越不在乎自己是谁。 它们真正的选择，并不是在开放和封闭之间二选一。它们既希望自己的能力被更多Agent使用，又不希望失去品牌、客户关系和定价权。
要思考的是：怎样开放能力，同时保留差异化优势？可以继续经营自己的产品和客户服务渠道，同时提供标准化接口；让外部Agent完成日常操作，但保留复杂的专业服务；让用户能通过Agent发现自己的产品，却不把所有客户关系都交给某一个Agent平台。
换句话说，开放自己的能力，不等于放弃自己的产品。
再看第二类，有些软件公司赚钱的关键，不仅是提供某种功能，还在于掌握用户进入服务的入口，以及用户在这个入口里的行为。
最典型的，是一部分内容平台、电商平台和生活服务平台。 沿用买鞋的例子，平台担心的不只是Agent替用户省了几次点击，而是筛选、排序和购买决策转移到了外部。
如果用户仍在平台下单，却不再经过它的搜索和推荐流程，交易收入可能还在，广告和推荐的价值却会变化。 这里改变的是价值分配，而不是平台价值凭空消失。供应链、物流、售后和交易保障仍然重要，品牌、内容和社区也仍能帮助用户发现商品。但如果筛选和决策转移到外部Agent，依赖广告曝光和站内推荐的收入就可能受到影响。
这也是为什么一些平台愿意开放商品查询，却对完整的自动下单流程更加谨慎。 需要特别强调：这并不是国内软件独有的问题。
2026年9月，亚马逊（Amazon）阻止了Meta的Muse Agent访问其购物网站，并要求Meta把亚马逊从Muse的体验中移除。亚马逊方面认为，未经授权的自动化访问违反了相关使用条件。
这说明，即使是海外平台，也不会因为Agent代表用户执行任务，就自动允许它访问自己的所有服务。至于亚马逊的具体动机，也不能简单归结为保护商业入口：自动化访问、安全风险、订单责任和商业利益，都可能是需要考虑的因素。
所以，真正的问题是：当Agent开始介入用户与软件之间的关系，每一家平台都需要重新考虑，哪些能力可以开放，哪些边界必须保留，以及开放之后，自己的商业模式会发生什么变化。
下一部分，重点看这些能力能否在安全可控的前提下，支撑Agent完成完整任务。
开放，怎么才能变成真正的竞争力？
一个软件开放了API或MCP，是否就意味着Agent真能把事情办成？软件能力能够被调用，与跨系统可靠地完成任务之间，仍有很长一段距离。
AI要把事情办成
假设你让一个AI助手帮你安排一次出差。
它需要查公司日程，看哪天有空；订机票、订酒店；把行程写进日历；最后整理一份出差计划，可能还要提交公司的出差申请。
这件事听起来不复杂，但仔细想，它跨越了好几个软件：日历是一个系统，机票和酒店是另外的系统，公司审批流程又是一个系统，各自有自己的账号、权限、数据格式和业务规则。 对Agent来说，它真正想完成的不是打开五个软件，而是完成一件事情。
如果每个软件只开放一个查询接口，AI也许能查到机票价格，却不一定能完成预订；如果它能查酒店，却不能读取你的日历，就不知道订的酒店和会议时间是否冲突；如果它能填写申请表，却不知道公司最新的审批规则，提交上去的东西也可能是错的。
所以，问题不是有没有接口，而是这些接口能不能连成一条完整的业务链路。 这条链路还必须足够可靠。机票订好了，酒店却没订成功，怎么办？
AI重试一次，结果重复下单，怎么办？提交申请时系统超时，AI怎么判断申请到底有没有提交成功？发现自己的操作和用户原来的要求冲突，又该怎么处理？这些问题，我们自己操作软件时也许不觉得复杂，因为我们能随时停下来，看看屏幕，判断一下，再做下一步。
但当Agent开始替我们执行任务，这些原本由人来兜底的环节就必须重新设计：让Agent能在清晰的边界内自主执行，超出边界时停下来交由人判断。这也意味着，软件开放给AI的能力不能只停留在孤立的功能上；外部系统还需要理解这些能力的用途、使用条件、权限边界，以及失败后的处理方式。
所以，接口要支撑的是完整结果，而不是一串孤立的操作。同时，任务链必须能表达不同的权限：允许查询，不代表允许修改；允许创建订单，也不代表允许直接付款。这些边界应该成为流程的一部分，而不是等执行出错以后再由人补救。
真正麻烦的是另一种情况：软件没有提供清晰的授权机制，也没有稳定的业务接口，而是要求AI像一个普通人一样，通过点击按钮、识别屏幕、模拟输入来完成所有操作。这当然也能做。如果软件暂时无法提供正式接口，AI也可以从用户视角操作界面：观察屏幕、理解界面，再模拟点击和输入，跨应用完成部分任务。
但这条路很依赖具体界面，也不一定能准确反映软件内部的状态：点击了提交，不代表服务器已经成功处理；看到订单页面，也不一定意味着订单状态已经最终确认。这就像让一个人隔着玻璃窗操作一台机器，他看得见按钮，也能按按钮，却未必知道机器内部到底发生了什么。 如果软件愿意提供正式的接口，明确告诉AI哪些操作可以做、成功后返回什么结果、失败时如何处理，事情就简单得多。
从长远看，为Agent提供正式的业务能力接口，通常比单纯依赖界面模拟更容易实现稳定的自动化。 现实中，很可能两条路线长期并存：能通过正式接口完成的事情，优先走接口；没有接口或必须观察真实界面的事情，再通过界面操作来补充。
重要的是，不要把技术手段本身当成目标。最终要看的是，AI能不能把事情办成。
开放到底成本高不高？
接下来是一个很现实的问题：开放的成本高不高，有没有商业价值？
很多人一谈到开放，就觉得是一件很复杂的事。一个软件原来只服务自己的用户，现在还要服务外部AI；原来只需要考虑自己的界面和流程，现在还要考虑不同Agent的调用方式、权限控制、异常处理。这当然会增加工作量。
有一项关于REST API如何适配Agent的研究，分析了50个真实API、共5066个端点。研究人员发现，如果把这些API直接自动转换成MCP工具，初始的工具调用成功率是76.5%；对API描述做小幅修正之后，成功率提高到了99.9%。
研究还报告，平均每个API需要修改约19行规范描述。 这说明，对一部分已经存在、设计相对规范的API来说，让它们更容易被Agent理解和调用，并不一定需要推倒重来。有时候，问题出在接口说明不够清楚，而不是底层能力缺失。
人类开发者看到一个接口，可能凭经验猜出参数是什么意思，也知道遇到某种错误该怎么处理，但AI不一定猜得对。
比如，一个接口要求传入一个状态值，文档只写了字段名称，却没有解释它有哪些合法取值。人也许能通过界面或其他文档推断出来，AI却可能反复尝试，直到碰巧成功，或者直接失败。对AI来说，接口描述本身就是工作环境的一部分。
因此，软件工程会出现新的要求：接口不仅要设计给开发者用，还要设计得足够明确，让AI能理解它、正确调用它，并且知道什么时候不该调用它。业界也因此越来越多地谈到一种软件形态，叫做“无头软件”（headless software）。
这个概念不是AI时代才出现的。过去的软件架构里，就已经有无头内容管理系统、无头电商系统这样的设计。它到底是什么意思？
可以把软件想象成一家餐厅。过去的软件，前台和后厨往往紧密连在一起：用户必须走到前台，按照餐厅设计好的菜单和流程点餐，后厨再根据订单做菜。无头架构的思路，是把前台和后厨分开。餐厅还是那个餐厅，菜也还是那些菜，但现在除了顾客到店点餐，外卖平台也可以接单，企业客户可以批量订餐，其他经过授权的系统也可以按规则下单。
区别在于，餐厅的业务能力不再只能通过原来那一个前台来使用。 软件也一样。一套库存系统，不应该只能让员工打开网页、找到库存页面、点按钮查询。它背后的查询库存、创建出库单、更新库存状态这些能力，可以通过明确的接口提供出来：原来的界面照样能用，其他业务系统也能用，Agent同样有机会调用。
所以，无头不是说软件没有界面，而是说，软件背后的能力不再必须依附于某一个界面。这样的软件，对AI智能体的操作才有意义。
真正困难的部分，往往不是把一个接口接出来，而是把整个业务过程做可靠：多个系统之间的事务一致性，重复操作的幂等性，用户身份的授权管理，调用失败后的恢复机制，以及数据泄露时的审计和责任认定。这些都不是多写几行接口描述就能解决的。
所以，软件公司考虑开放时，不能只算第一笔开发费用，还要算一笔更长期的账。 如果一个能力被设计成标准化接口，以后不管是自家的AI助手、客户自己的Agent，还是第三方开发者的Agent，都可能通过同一种方式使用它。
今天为一个接口投入的开发成本，未来就有机会被更多不同的应用重复利用。反过来，如果每个Agent都必须单独适配一套特殊的界面操作，或者每接入一个新的AI平台就要重新开发一遍，集成成本就很难持续下降。
这和过去的软件工程有点像。过去，一个企业要把几十个系统连起来，每个系统用完全不同的数据格式和通信方式，系统之间的集成就会非常复杂。后来，API、标准协议和统一的身份认证机制逐渐普及，至少让一部分集成工作变得规范。
现在，Agent可能把这个问题重新带回来，只不过过去连接的是系统和系统，现在还要考虑AI如何发现、理解和调用这些系统的能力。而且，Agent不只是传递一条固定指令：它可能需要根据执行结果，临时决定下一步做什么；发现信息不足时，主动查询；发现任务无法继续时，请求人来确认。
这就要求软件提供的能力不仅能被调用，还要足够清晰、可组合，并能反馈真实的执行结果。 未来需要一套更具体的评价标准。
如果你是一家软件公司的负责人，想知道自己的产品有没有做好面向Agent的开放，不能只问一句“我们有没有MCP”，而应该问几个更实际的问题：
外部Agent能不能发现并理解我们的能力？ 如果工具的名称和描述含含糊糊，AI根本不知道什么时候该用它，那么即使开放了，也没有太大的实际价值。 用户授权之后，Agent能不能完成一项完整的任务？ 不要只测能不能查到一个数据、能不能创建一条记录，而要测一个真实的业务场景：从任务开始，到执行，再到最终结果确认，整个过程能不能跑通。 任务失败时，系统能不能给出明确的反馈？ AI需要知道是权限不足、参数错误、服务超时，还是业务规则不允许。如果所有失败最后都变成一句模糊的“操作失败”，Agent就很难自行恢复。 权限能不能做到足够精细？ 用户不应该因为授权一个简单任务，就把整个账号的所有能力都交出去。能查询的，不一定能修改；能创建的，不一定能删除；能提交的，也不一定能直接完成资金支付。 整个过程的成本究竟是多少？ 包括接入开发需要多少人天，完成一次任务需要多少次工具调用、多少次人工接管，失败之后要花多少时间恢复，每完成一项业务要消耗多少资源。
把这些指标记录下来，才能判断软件能力是否真正适合Agent稳定调用。 这也会带来另一个变化：软件怎么收费。我们熟悉的SaaS收费方式，是按用户数量、按账号、按年订阅，买多少个席位就付多少钱。
当越来越多的使用者变成Agent，软件公司就可能需要考虑另一种方式：按调用次数、处理的数据量、完成的业务量来收费。比如，模型可以按使用量收费，云服务可以按资源消耗收费，某些专业软件可以按处理了多少份文件、完成了多少笔业务来计费。当软件能力能够脱离原来的界面，被其他Agent单独调用时，这些能力就更有机会成为可以独立计量、独立定价的服务。这不仅是接口怎么设计的问题，也是软件公司重新组织产品和收入结构的问题。
这样，软件的服务性和开放性，才能变成一种重要的竞争力来源。
未来的软件，为什么应该成为一种资源？
前面讨论了开放如何落地，接下来看看它会怎样改变软件的使用方式：个人应用、专业工具和企业系统，会分别发生什么变化？
个人Agent会重新组织我们与个人数据的关系
先从一个离我们比较近的场景说起：健康管理。
如果你戴着一块Apple Watch，每天记录活动、运动、心率和睡眠；手机里有健康数据，可能还有饮食记录、体检报告，以及其他健康服务留下的信息。这些数据原本散落在不同的应用里，每个应用都有自己的功能和数据结构。
想了解自己的整体情况，就得在不同应用之间切换，有时还得手动整理。 但你想要的，并不是同时打开五六个健康应用，而是：最近一个月，我的睡眠有没有变化？运动量增加之后，恢复情况怎么样？最近几天为什么总觉得疲劳？如果我准备调整作息，有哪些值得注意的地方？这需要把不同来源的信息放在一起，结合时间、生活习惯和你的目标，才能形成一个更完整的判断。
如果有一个个人助理智能体，能在你明确授权的前提下读取这些分散的数据，再根据你的问题调用相应的分析能力，它就有机会把原本割裂的应用组织起来。这里最重要的变化，不是某个健康应用突然变得更聪明了，而是你不再需要完全按照每个应用自己的方式来使用数据。你可以继续使用Apple的健康应用，也可以使用其他记录工具；但在它们之上，还可以有一个更贴近自己需求的智能助手，按你关心的问题把不同来源的信息组织起来，就像ChatGPT里推出的“健康”功能。 还有一个值得注意的区别。
原来，用户换一个应用，就意味着要重新建立一套使用习惯，甚至要自己重新整理数据。
如果数据能在用户授权下被不同的Agent和服务使用，用户选择服务的自由度就会大大增加：你可以换掉某个分析工具，而不必失去长期积累的数据；也可以尝试新的Agent，而不必从头开始记录所有信息。
对用户来说，这代表选择权的增加；对软件公司来说，则意味着：如果用户的价值不再完全依附于某个应用，你就需要持续证明，为什么用户还应该使用你的服务。
从方向上看，个人Agent带来的变化，是让用户有机会从一个个独立应用的使用者，变成自己数据和任务的组织者。
专业软件不一定会消失，但它的使用方式和价值判断肯定会发生变化
再看面向某个领域的专业软件。
一个专业软件的价值，通常体现在它的功能有多强大，以及用户要花多长时间才能掌握它。做设计的人要学设计软件，做数据分析的人要学分析工具，程序员要学开发环境。很多专业软件功能非常强大，但要真正用好，需要长期积累经验。这并不奇怪，复杂的专业任务本来就需要专业的工具。 但Agent出现之后，有一件事正在变化：用户不一定还需要亲自操作专业软件的每一个功能。
以图像和视频制作为例。原来，一个设计师要做一张专业海报或一段视频，往往要打开Photoshop、Illustrator、Premiere、After Effects这样的软件，学习不同的工具，理解图层、蒙版、时间轴、关键帧等概念，再一步步完成创作。即使经验丰富的设计师，也要花大量时间调整：先生成或拍摄素材，再修图、抠像、调色、合成画面、加字幕、做转场，最后导出不同尺寸和格式的文件。其中相当一部分工作，并不是在做创意本身，而是在学习和操作工具，在不同工具之间搬运素材、调整参数、反复修改。
现在，你可以直接告诉AI：我需要一段一分钟的产品宣传视频，整体风格简洁、现代，突出产品的三个核心卖点，分别面向手机和大屏幕输出。接下来，AI可以帮你生成图像和视频素材、整理文案、设计分镜、制作字幕，甚至调用不同的工具完成部分后期处理。随着Agent能力的发展，它还可以根据任务需要调用不同的软件或服务，检查生成结果，再决定下一步怎么调整。 这时，用户与专业软件的关系就可能发生变化。
过去，你需要先学软件提供了哪些功能，再想办法用这些功能实现自己的创意；如今，你只要描述自己想要什么，再让Agent决定该用哪些工具、调用哪些能力，以及怎样把不同的处理步骤组合起来。
这并不是说图像和视频软件变得不重要了。精细的图像处理、复杂的图层合成、色彩管理、视频剪辑、关键帧控制、特效合成，以及专业格式的导入导出，这些能力不会因为出现了一个AI助手就自动消失。但它们目前都是为人类用户服务的，给智能体提供的能力还比较少。
如果一个图像处理软件能提供清晰的素材管理、图像编辑、图层操作和导出接口，Agent就有机会直接调用这些能力，把它们融入更长的创作流程。如果一个视频软件能让Agent读取时间轴上的素材、调整剪辑片段、添加字幕、执行渲染，并返回明确的处理结果，Agent就能把这些操作组织起来，而不必每次都依赖模拟鼠标点击和键盘输入。
当然，专业软件的价值还包括它积累的算法、数据、工作流程、质量控制和行业经验，不会这么简单就被AI拿来用。但专业软件从“卖一个应用”转向“对外提供一种专业能力”，这个趋势已经不可逆。
同样的变化，也出现在编程、数据分析、财务处理、法律文书等各类专业领域。 专业软件的竞争方式可能会更加多样，专业价值也会更多体现在持续深入、细化并可靠交付某一类能力上。
企业软件正在从信息系统变成AI执行的基础设施
如果说个人Agent解决的是个人任务的组织问题，专业Agent解决的是复杂专业工作的执行问题，那么企业Agent面临的，是更加复杂的业务流程。
一家企业里通常有大量信息系统：客户信息在客户关系管理系统里，合同在合同管理系统里，采购有采购系统，财务有财务系统，人力资源有自己的系统。它们各自负责不同的业务，也有自己的权限、数据和审批流程。这些系统可能已经运行了很多年，投入巨大，积累了大量业务规则。当初为什么设置这些规则，业务人员可能都已经不知道了，但系统仍在按那套规则运行。
过去，为了不让员工在不同系统之间切换，就要通过项目建设把它们集成起来。即使系统之间已经实现了一定程度的数据互通，面对真正需要跨多个部门完成的业务时，仍然需要大量人工协调。这件事并不是把几个系统连起来就结束了，因为完成一项完整任务，必须遵守一整套跨部门的企业级流程和规则。
以后，如果企业的Agent要参与其中，就必须理解任务的目标，知道需要调用哪些系统、按什么顺序执行，并在遇到权限不足、规则冲突或异常情况时停下来，交给人处理。这时，企业软件能否开放自己的业务能力，就会变成一个非常实际的问题。 如果采购系统只能让员工打开页面、手动填写表单，Agent就只能尽可能模拟人的操作。如果它能提供规范的申请创建、预算查询、供应商检索和审批状态查询接口，Agent就有机会按企业授权的流程调用这些能力。
更进一步，如果不同系统都能以一致、明确的方式描述自己的能力，企业就可能在它们之上建立新的任务编排层，让Agent根据具体的业务目标，动态组织不同系统的操作。 需要说明的是，企业Agent并不能绕开企业原有的管理制度，除非企业自身的管理流程也在朝AI原生的方向进化。
短期来看，真正能进入企业核心业务的Agent，必须服从企业已有的身份管理、职责分离、权限控制、审计和审批机制。
企业要做的，不是把所有系统的权限一股脑交给一个智能体，而是把业务规则和权限边界变成机器能够识别、执行和审计的机制。如果这件事能逐步实现，企业软件的角色就会发生变化：它会成为企业Agent完成工作时调用的底层能力。
企业也就有机会通过Agent，把已有系统中的能力重新组合，快速形成新的工作流程，从而改变原有的企业创新成本结构。 换句话说，AI可以通过重新组织已有的软件能力，来创造新的业务价值。
软件变成资源，并不意味着软件公司不再重要
这三个场景有一个共同点：用户可以围绕任务重新组织软件能力，而不必完全服从某一个产品的操作路径。
随之改变的，是价值和责任怎样分配：谁理解用户目标，谁提供关键能力，谁确认最终结果，谁承担失败风险，又由谁获得收入？这些问题需要新的协作和商业规则，不能只靠把接口接通来解决。
如果企业仍然只关注守住原有入口，却没有找到自己在新任务链中的价值，就可能错过这些机会。接下来反过来看：坚持原来的封闭策略，会付出什么代价？
过度封闭的代价
从技术上看，大家都希望自己的软件能被更多工具使用，自己的能力能服务更多用户。
从商业上看，每家公司又都希望用户留在自己的产品里，最好从进入应用、获取信息到完成交易，整个过程都发生在自己的地盘上。这两种想法并不总是一致。
回头看过去几十年的软件产业会发现，封闭并不是一种愚蠢的策略，很多时候，它恰恰是软件公司获得竞争优势的重要手段。 所以，得先理解封闭究竟是怎么形成的?
封闭曾经是一种非常有效的商业策略
一家企业投入多年积累产品、用户和技术，希望控制这些能力的使用方式，并不难理解。封闭曾经帮助企业保护投资、维持客户关系，也让订阅、广告和交易等收入能够在自己的体系内实现。
前面已经讲过入口经济，这里更值得追问的是：当技术条件改变，过去有效的组织方式是否仍然有效？封闭并非简单地不愿分享技术，但它也不能因为曾经成功，就自动成为未来正确的策略。 问题在于，这种组织方式有一个技术前提：用户需要通过软件公司自己提供的界面来使用服务。
而智能体正在改变的，恰恰是这个前提。用户不一定再需要打开你的App，甚至不知道Agent在完成任务的过程中调用了哪些服务。 如今AI应用发力的重点，都是把用户的注意力从“我应该打开哪个软件”，转向“我想完成什么任务”。
这两种关系有很大区别。 这就是封闭面临的第一个问题：即使今天保护住了自己的应用入口，也不一定能保护住自己参与未来新业务模式的机会。 除了商业模式，还有软件开发成本的问题。
过去，开发软件的成本比较高，打磨周期也很长，才能积累一套成熟的产品；别人想做一个类似的东西，可能也要投入几年。这段时间，就是你的竞争壁垒。
现在，AI正在改变这件事。
一方面，AI编程工具正在大幅降低软件开发成本。一个人借助AI，有机会在很短时间里做出一个功能相当完整的软件。这不意味着一个人就能轻易复制成熟的企业级软件，但至少，做出一个可以运行的替代品，正在变得容易得多。
另一方面，AI不仅能帮人从零开始写软件，还能帮人研究已经存在的软件，理解它是怎么工作的。最近在GitHub上很火的开源项目REA，全称Reverse Engineer Anything，直译过来就是“逆向工程任何东西”。
它把AI编程Agent和传统的逆向分析工具连接起来，让AI帮助分析一个已经编译好的程序，研究它的功能是怎么实现的，再尝试重建相应的功能。 有人用它复刻了Photoshop约80%的功能，有人把Switch上的游戏《塞尔达》移植到了Mac电脑上，而这一切都不需要经过原来的软件公司，在家里用AI就能做到。
过去，理解和重建一款软件的难度，本身就是竞争门槛。AI可能削弱这道门槛，但这并不意味着软件公司必须无条件开放。它说明的是：不开放接口，并不能保证竞争者无法实现类似的功能。
如果用户能通过屏幕操作使用你的软件，逆向分析者就可能研究它的行为；如果你的软件能在本地运行，别人就可能分析它的程序；如果你的核心功能并不依赖独有的数据、算法或难以复制的业务体系，AI就可能帮助竞争者更快地重建其中一部分。
这意味着，单纯依赖代码不公开、接口不开放和理解门槛来维持竞争优势，可能越来越不可靠。 这里甚至存在一个有点讽刺的局面：你越是想把所有能力都关在自己的应用里，就越可能让外部开发者无法通过正规接口使用你的服务；可如果你的核心能力又不够独特，别人就可能转而研究你的软件，用其他方式实现类似的功能。
当然，开放接口也不能完全阻止逆向工程。但从商业策略的角度看，与其把精力都放在阻止别人接触自己的能力上，软件公司更应该思考：如何通过更好的服务、更独特的能力、更可靠的交付和合理的商业规则，让用户持续选择自己？当开发成本和逆向分析成本都在下降，竞争优势越来越难仅仅建立在“别人做不出来”上。
软件公司必须回答一个问题：即使别人也能做出类似的功能，为什么用户仍然应该选择你？ 用户入口的迁移，以及部分功能重建成本的下降，这两种变化都在提高封闭策略的代价。接下来看看小工具和大平台分别可能失去什么机会。
小软件的封闭，可能让自己越来越难被发现
先说规模不大、功能比较单一的软件，比如专门处理PDF的工具、做图片转换的软件、整理文件的工具，或者帮助用户完成某项专业工作的应用。这类软件的价值，可能就在于某一个具体的功能。
用户先要知道它存在，下载、注册账号，再学习怎么使用；软件公司也要投入成本做推广，让用户知道自己能解决什么问题。 未来，用户可能不再需要专门去找这些工具软件。
比如，用户只需告诉Agent：“把这几份合同里的付款条件提取出来，按金额和日期整理成一张表。”Agent可能会调用文档解析、文字识别、表格处理等不同的能力来完成这项工作。这些工具都内化成了智能体的基础操作能力，也就是常说的tool use，甚至包括对底层操作系统的操作，例如现在流行的computer use和phone use。
在这种情况下，用户根本不关心每个底层工具叫什么名字，只关心任务能不能完成，结果是否准确，成本是否合理。
如果一家小软件公司拥有非常好的文档解析能力，并能以稳定、清晰的方式向Agent提供服务，它就可能通过其他Agent获得用户，而不必完全依赖传统的应用商店、广告投放或搜索排名。这对小公司甚至可能是一种机会。
反过来，如果它的能力只能通过自己设计的界面使用，外部Agent很难发现它，也无法稳定调用它，那么即使功能不错，也很难进入用户的工作流程。结果可能是，它既用不上Agent带来的新分发渠道，也没法让其他开发者更方便地使用自己的专业能力。
大平台的封闭，可能保护了入口，却限制了生态
再看互联网大平台。大平台和小软件不一样，通常拥有大量用户、丰富的数据、完整的业务体系，以及较强的品牌和分发能力。
它们当然有理由保护自己的入口。但也正因为拥有大量资源，一旦决定开放部分能力，就有机会为整个生态提供非常重要的基础设施：地图平台可以提供地理位置和路线规划能力，办公协作平台可以提供文档、日历和协作能力，电商平台可以提供商品、库存和交易能力，支付平台可以提供经过授权的支付服务。这些能力如果能在明确的规则下被外部Agent调用，就有可能进入更多原本不属于自己的应用场景。
但如果每个平台都希望把用户完整地留在自己的应用里，拒绝让外部Agent以合理的方式使用自己的能力，企业就只能继续通过人工操作，或为每个平台单独开发复杂的集成方案。平台也许因此保住了一部分控制权，但整个生态的协作成本也会增加。
更大的区别在于，平台会逐渐发现，其他公司正在围绕用户任务建立新的服务体系，而自己还在固守原有的阵地。 如果一个平台不愿成为其他Agent的能力提供者，其他Agent就可能寻找替代服务，或由新的服务商把相关能力重新组织起来。
大平台不能因为今天拥有入口，就假设未来所有重要的用户行为仍会经过这个入口。大平台的风险不一定是明天就失去用户，而是过度依赖原来的控制方式，以至于错过了下一种组织软件能力的方式。
国内软件真正需要面对的是什么？
问题还需要再往深处挖一层。 前面讲了软件入口，讲了商业模式，也讲了AI降低了软件开发和逆向分析的成本。
但如果审视国内的软件生态，会发现封闭带来的影响更值得关注。如果你经常使用现在的各种AI智能体工具就会发现：在软件开放、跨应用连接，以及让第三方开发者组合能力这些方面，国内和美国相比整体上确实还有不小的差距。
深挖背后的原因，我认为至少有六个方面：前五个主要来自商业模式、产业结构和协作机制，第六个则是更深层的开放观念问题。
第一，国内互联网过去的巨大成功，很大程度上建立在大公司、大平台的超级入口模式之上。
微信、支付宝、淘宝、抖音、美团，这些平台过去二十年的成功，很大程度上来自把用户、内容、商家、交易和服务集中到自己的平台里，也就是常说的super app。这种模式在国外并不多见。用户在一个App里就能完成很多事情，平台也可以统一管理体验、交易和风险。
于是，这些公司逐渐形成了一种特有的产品思维：与其让我的能力被其他平台调用，不如把更多服务吸引到自己的生态里来。微信有自己的小程序生态，支付宝有自己的小程序生态，抖音有自己的内容和交易生态。它们确实向第三方开放了很多能力，但这种开放，主要是让第三方进入自己的平台，而不是让自己的能力自由进入其他平台。
这两个方向看起来相似，实际差别很大：一个是希望整个生态围绕自己运转，另一个是让自己成为更大生态中的一个能力节点。前者强调平台控制力，后者强调互操作性。所以，这些平台天然会对开放有所保留。这不一定是企业不懂技术，而是过去的成功模式，决定了它会怎样看待开放。
第二，流量生意让开放变得更加矛盾。
这一点和第一点有关，但直接关系到Agent会怎样改变软件公司的收入。前面讲过，Agent会压缩用户的浏览和筛选过程。
对依赖流量变现的平台来说，开放的难点不仅是增加接口成本，更是可能减少原有的收入。因此，转型需要找到新的计费和利益分配方式，而不只是要求企业改变态度。
第三，国内软件产业过去更擅长经营消费互联网平台，而不是围绕企业服务和开发者协作建立能力网络。
海外有Salesforce、Stripe、Twilio、HubSpot这样的公司。它们当然也经营自己的产品，但同时也围绕API、开发者平台、应用市场和第三方集成建立生态。其他开发者可以基于这些能力开发新产品，另一家软件公司也可以把这些能力整合进自己的业务流程。
软件之间形成了比较细密的分工：有人提供客户管理，有人提供支付，有人提供通信，还有人负责把这些能力连接起来。这种生态一旦形成，软件就不再只是一个个独立的产品，而会逐渐成为可以相互组合的能力网络。
从整体产业结构看，国内过去的注意力和资源，更多集中在消费互联网、超级App和平台经济上；围绕企业软件、专业工具、开发者服务和跨产品集成形成的商业生态，相对没有那么成熟。这会带来一个后果：当一家公司主要靠经营自己的平台赚钱时，它不一定有动力让其他平台轻松使用自己的能力；但如果一家公司的收入本来就来自向其他企业提供专业服务，让更多软件连接进来，就可能直接扩大它的市场。
换句话说，开放只有成为一种稳定的收入来源，企业才更有动力把它做成长期的产品能力，而不是一个附属的技术项目。
第四，企业之间的信任不足，围绕开放形成的治理机制也还不够成熟。
授权、审计和责任归属的要求，前面已经讲过。放到产业生态中，还要解决一个额外的问题：不同企业能否接受同一套规则，而不是每次合作都从头谈判、从头评估风险？
这并不是国内独有的问题。标准化的身份认证、权限撤销、开发者规则和商业协议，只有得到多方长期遵守，才能降低协作成本，让企业敢于把外部能力接入真实业务。
第五，我们对软件开放的理解，有时候还停留在“提供接口”的层面。
前面讨论的任务完成率、异常恢复、精细授权和服务计费，不能都被当成接口项目的附属工作，它们需要进入产品设计、研发预算和长期运营。如果团队只负责“把接口发出去”，却不负责外部任务能否持续跑通，开放就很难成为稳定的产品能力。
第六，也是更深层的：除了商业模式和技术架构，我们在开放精神上，也同样需要反思。
回看现代软件产业的发展历史，自由软件运动、GNU、Linux，以及后来形成的许多开源社区，都有很强的国际协作传统。互联网的许多开放标准，也是在W3C、IETF这样的国际组织中，通过长期协作逐步形成的。这些组织做的不只是把代码公开出来，而是建立一套共同参与、共同维护、共同制定规则的机制。
一个人可以使用别人开发的软件，可以在它的基础上继续开发，也可以把自己的改进贡献回去；一个组织提出了技术标准，也不意味着它能独占这个标准带来的全部价值。
这些模式背后有一个重要的观念：不一定要控制整个生态，才能从生态的发展中获得价值。 只要大家共同把一件事情做好，都可以从中受益。
当然，海外开源社区并不是没有商业竞争，大型科技公司也会争夺标准、控制平台；国内同样有很多优秀的开源项目和开发者。但从整体的发展历史和生态成熟度来看，现代开源运动、全球开发者协作机制，以及许多重要的开放标准组织，确实主要是在国际化的技术社区和组织网络中逐渐发展起来的。
国内过去更多是参与、使用和跟进这些生态。近年来，中国开发者和企业在全球开源社区中的贡献不断增加，但我们仍然需要思考：除了贡献代码，能不能建立更多由国内团队发起、又能吸引全球开发者持续参与的项目和组织？ 一个项目能不能吸引不同国家的开发者长期参与，不仅取决于技术质量，也取决于治理方式、规则透明度、贡献者体验，以及项目是否愿意让不同背景的参与者共同影响它的发展方向。
这是一种观念上的区别。 我们应该把开放理解成一种协作方式：能不能通过共同的标准、透明的规则和合理的商业机制，让更多参与者一起创造价值？
把这六个层面放在一起，就能看到，开放不是一个孤立的技术问题，也不是一句“企业应该有开放精神”就能解决的问题。
商业模式决定企业有没有动力开放，产业结构决定开放能不能形成规模，信任和治理决定开放能不能安全地持续，产品架构决定开放能不能真正落地，而开放精神决定我们是否愿意把外部参与者当成共同创造价值的伙伴，而不只是需要防范的竞争者。
这些因素相互影响，最终形成了一种软件生态。
如果想要了解详细内容的朋友，可以移步播客平台收听本期节目
