过去五十年，软件只有一类使用者：人。
所有的设计决策都建立在这一点上——视觉层次是为了让人快速定位，引导流程是为了让人不迷路，模糊容错是为了让人不至于因为一次误操作而崩溃。文档写给人看，错误信息考虑的是人类的理解能力，定价按席位计算，因为价值随人数增长。
现在，第二类使用者出现了。它不读界面，不看引导，不理解隐喻，也不介意流程有多丑。它只关心一件事：这个能力能不能被稳定、确定、结构化地调用。
一件已经发生的事
看一个具体的例子。假设你做了一个项目管理工具，人类用户通过看板拖拽任务。现在你接入了 AI 编程助手，希望它能在收到某个 issue 时自动创建任务。
它不会打开你的界面。它会去找你的 API。如果 API 不存在，它会尝试用浏览器自动化去点按钮——这是最坏的情况，慢、脆弱、容易失败。
它会遇到什么问题？
- 文档里写着「创建一个任务」，但没写清楚哪些字段必填、哪些字段互斥。
- 参数叫
title，但描述是「任务标题」——没有说明是否会去重、是否支持 Markdown、超长怎么处理。 - 出错时返回
{"error": "invalid request"}。对人来说这已经够糟了，对 Agent 来说，这等于没有信息。 - 权限模型只有「读写」两档，没有「允许创建但不允许删除」。
这些问题以前也存在，只是代价由人承担——用户多点两次、看看文档、试试看。现在代价变成了任务失败与不可预测的行为。
三个正在转移的重心
第一，文档从体验问题变成功能问题。
给人写文档，含糊是可以被容忍的，因为人会追问、会试探、会根据上下文猜。给 Agent 写文档，含糊会直接转化为错误调用——而且往往是静默的错误：它不会报错，只是做了错的事。
于是「文档质量」从一个软性指标，变成了决定系统能否工作的硬性接口。这也是为什么 MCP 这类协议值得关注：它们做的事情之一，就是把「工具的能力描述」标准化成机器可以依赖的格式。
第二，可发现性取代了品牌。
人选择软件靠品牌、口碑、评测、同事推荐。Agent 选择工具靠描述的区分度与能力是否可组合。
这意味着一个残酷的推论：如果你的工具和另一个工具描述相似、边界模糊，Agent 会随机选一个。品牌溢价在这里完全不起作用。
第三，定价模型需要重做。
按席位收费的逻辑，隐含的假设是「人越多，价值越大」。当企业里一个人带着三个 Agent 工作时，这个假设失效了。
更麻烦的是成本结构变了。传统 SaaS 的边际成本接近于零，多一个用户几乎不增加成本。当 Agent 每秒调用你一百次时，每次调用都有真实的计算成本。你需要一套新的定价模型，而它的前提是你得先知道自己每次交付了多少价值。
但不要过度推演
市面上关于这个话题的讨论，有三个方面被明显高估了。
「App 会消失」——不太可能。人仍然有为人设计的场景：探索、决策、社交、审美。更可能的形态是双重接口：给人用的界面，给 Agent 用的协议，共享同一套底层能力。
「所有软件都要重写」——多数软件只需要在现有 API 上补三样东西：清晰的描述、细粒度的权限、结构化的错误信息。这三件事今天的工程团队就能做。
「界面设计不重要了」——恰恰相反。当所有软件都能被 Agent 调用时，人类使用的那部分反而成为唯一的差异点。
四个今天就能回答的问题
与其猜未来，不如回答几个具体问题：
- 如果你的产品只暴露 API，还有价值吗？ 如果答案是没有，说明价值主要来自界面。这不一定是坏事，但需要意识到风险。
- 你的文档能让 Agent 一次就正确调用吗？ 找个人工智能助手试试，看它需要几轮才搞对。
- 你的计费方式能容纳非人类用户吗？ 如果 Agent 数量远超人类用户数，你的定价会发生什么？
- 你的错误信息是给人看的，还是给机器解析的？ 加一个
code字段，成本极低，收益很高。
这四个问题不需要任何新技术就能回答。而答案，大概会决定几年后你在这个市场里的位置。
结论
软件并没有变简单，而是多了一类使用者。
为两类使用者同时设计，会在很长一段时间里成为产品工程的基本功。而那些把「可被 Agent 可靠调用」当作一等公民的产品，会在新的分发渠道里先拿到位置。
这不是未来学。它已经出现在你的 API 日志里了。