真正面向Agent的软件应该怎么设计？

最近越来越多人开始说，未来的软件要“面向 agent”来设计。很多人觉得说，那是不是以后所有软件前面都加一个对话框，用户直接用自然语言下指令，软件自动去完成任务，这就算 agent-native 了？我觉得不是。

“面向 agent 做软件”这件事，最容易理解错的地方就在这里。很多人把它理解成就是增加一种交互方式，只要把原来的按钮和表单换成聊天入口就可以了。聊天框只是入口，不是核心。真正需要改变的，是软件背后的组织方式。

差异性

过去的软件，默认第一用户是人。人要看页面，理解上下文，自己判断下一步该做什么，也能在流程卡住的时候凭一些人工方式补救。软件因此只需要把页面、按钮、表单和菜单做好，剩下的大部分流程理解以及如何使用，都交给用户自己完成。

但 agent 不一样。agent 并不擅长“看页面猜流程”，也不应该依赖大量隐含经验去做事。它更适合面对清晰的对象、明确的动作、结构化的状态、可验证的结果，以及边界明确的权限体系。也就是说，未来的软件如果真的要让 agent 成为重要使用者，就不能再只围绕页面和流程设计，而要围绕“任务是否可以被可靠执行”来设计。

举一个商务差旅的例子。这个场景很典型，因为它几乎具备了所有适合 agent 介入的特征。流程长，规则多，涉及审批，涉及预算，还涉及真实的预订和取消。一个员工要完成一次出差安排，先要提交出差申请，再看公司制度允许订什么票、住什么档次的酒店，然后比较时间和价格，再等审批，审批通过后继续预订，有时还要把行程同步给同事或者加进日历。表面上看，这是一个“订票”的问题，但实际上背后是一整条流程。

传统的软件会怎么设计这件事？通常是做出一整套页面。一个菜单里有“出差申请”，一个菜单里有“机票预订”，一个菜单里有“酒店预订”，还有“审批记录”和“报销管理”等等，不同权限的人可以访问不同的界面来完成属于自己的环节。软件把这些页面提供给用户，然后教会用户应该操作。但是先做什么、后做什么，什么情况下需要回退、修改、重新提交，都是靠用户的理解。换句话说，软件提供的是工具箱，而流程理解能力来自人。

这种模式在过去当然成立，因为人本来就是最主要的执行者。问题是，如果我们希望 agent 来承担越来越多的执行工作，这种设计就会变得不可靠。因为对 agent 来说，菜单结构不是能力结构，页面入口也不是任务入口。它更需要的是明确的动作定义：创建差旅申请、检查差旅政策、搜索符合规定的交通方案、搜索符合预算的酒店、生成行程方案、提交审批、正式预订、改签、取消。也就是说，软件不应该再只是“页面集合”，而应该逐渐变成“任务能力集合”。

这正是我觉得很多人现在还没有真正想明白的地方。所谓面向 agent 做软件，需要重新整理软件内部的能力边界。原本那些散落在多个页面上的功能，需要被抽象成 agent 能够理解和调用的 action。这些 action 不是随便把按钮名字拿出来就够了，它们还必须具备清晰的输入、输出、前置条件和失败原因。比如“提交差旅申请”不是一句模糊的话，而应该明确要求目的地、时间、出差事由、预算偏好；“检查差旅政策”也不只是返回一个能或不能，而应该告诉 agent 哪一项超出标准、为什么超出、有哪些允许的替代方案。

面向Agent的软件，需要改什么

当软件开始这样组织时，很多事情都会发生变化。过去，企业的差旅规定可能只是写在一篇制度文档里，大家靠自己阅读和经验去理解。比如北京到上海优先高铁，除非时间冲突；酒店每晚不超过多少预算；某个级别以上才可以订商务舱；红眼航班默认不推荐；超过两天的出差需要额外审批。对于员工来说，这些规则只要“差不多知道”，或者实在不清楚就到处询问就可以，因为总有人会“兜底”。但对 agent 来说，模糊规则就是风险来源。它不是不能做判断，而是不能把系统建立在“差不多”上。所以面向 agent 的软件必须把这些规则显式化、结构化。它要明确告诉 agent，哪些是允许的，哪些是限制的，哪些情况需要发起例外申请，哪些动作必须先经过人工确认。

再进一步，真正适合 agent 的软件，不能只提供一堆低层能力。因为很多软件虽然已经有 API 了，但那并不代表它已经面向 agent。API 可能只是把页面动作程序化了一遍，仍然需要调用方自己把十几个步骤拼起来。可 agent 最擅长的并不是盲目拼装细碎动作，而是在较高语义层面上完成任务。所以一个更好的差旅系统，不应该只提供“订机票”和“订酒店”，它还应该直接提供类似“规划一次合规商务出差”这样的高阶能力。输入是目的地、日期、出行目的、预算偏好和出行人信息，输出则是符合公司政策的交通方案、酒店方案、审批要求、行程预案，以及当前仍然缺失的信息。这样一来，agent 不需要自己在底层摸索流程，而是站在更高层完成任务，效率和稳定性都会更高。

不过，仅仅有动作和规则还不够。面向 agent 的软件还有一个被很多人忽略、但实际上非常关键的点，就是状态表达必须足够清楚。传统软件里，一个“处理中”往往就能糊弄过去。人看到这三个字，大概知道还没结束，也会自己继续追踪。但 agent 不行。它需要知道当前到底在哪一步，为什么卡住，下一步允许什么，不允许什么。如果一个差旅请求只是显示“审批中”，对 agent 几乎没有帮助；但如果系统告诉它：当前状态是 awaiting_manager_approval，原因是行程超过预算阈值，需要部门负责人批准，下一步允许的动作是等待审批、修改预算方案、提交例外申请，那么 agent 才知道接下来该做什么，agent才可以足够稳定。

还有一点也很重要，那就是不要把“自动化”误解成“全自动执行”。面向 agent 的软件，并不意味着所有动作都应该让 agent 直接提交。恰恰相反，真正成熟的 agent 软件，往往会非常强调确认机制。因为很多动作本身就带有风险，比如付款、对外发消息、取消已有安排、修改正式记录、触发审批流程。一个好的系统，应该天然支持 analyze、propose、commit 这样的分层。agent 可以先分析，可以生成候选方案，也可以准备好执行草案，但在真正预订机票和酒店之前，仍然让人进行确认。比如系统先给出两个合规方案：一个更便宜，但出发时间更早；一个时间更舒服，但总成本略高。用户确认后，再执行真正的预订。这种机制不是在削弱 agent 的价值，而是在为 agent 落地创造条件。因为企业真正担心的，从来不是 agent 不够聪明，而是它会不会在不该自动执行的时候自动执行。

未来的软件，需要重新分工

所以“面向 agent 做软件”其实是一整套关于产品结构的重构。过去的软件在问：怎么让人更高效地交互？未来的软件更应该问：怎么让系统把一个任务包装成 agent 可以可靠完成的能力？这背后对应的是完全不同的设计哲学。前者的中心是操作逻辑，后者的中心是任务编排。前者默认流程理解能力在用户脑中，后者要求系统把流程本身表达清楚。前者容忍很多模糊和经验，后者必须把对象、状态、规则和边界显式化。

我觉得这也是为什么很多现在所谓的 agent 产品，给人的感觉还只是“看起来很先进”，但没有真正改变什么。因为它们常常只是把原本复杂、碎片化、依赖人类经验的软件表层包了一层自然语言入口，底层却没有重构。结果就是，看似很流畅，执行却很脆弱；演示看起来很惊艳，落地时却到处卡住。说到底，问题不是模型不够聪明，而是软件本身还没有准备好被 agent 使用。

如果从更现实的角度来看，我觉得真正值得做的是去找那些流程长、规则明确、结果可验证、风险边界清晰的场景，把其中一条最核心的工作流先重构出来。未来的软件当然不会完全抛弃人。更现实的图景是，人逐渐从手动点击、手动查规则、手动串流程，转向确认目标、审阅方案、处理例外情况。而 agent 负责在规则范围内执行大部分具体步骤。到了那个时候，好的软件的评判标准就变成了一个任务能不能在系统里被可靠完成。我觉得，这才是“软件面向 agent”真正值得讨论的方向。