前两天完整看了一场技术对谈嘉宾是我一直很尊重的一位研究者。他聊了很多但有一句话我反复回放了好几遍未来软件的第一客户不是坐在屏幕前的人而是替人跑腿的 Agent。这句话乍听像是行业最前沿的少数派观点可仔细一拆会发现它跟过去一年里很多技术团队悄悄在做的事情完全对上了。这篇文章不打算复述对谈的每一个细节而是顺着这条线索把“软件的第一客户变成 Agent”这件事拆开来看它改变了什么、对软件从业者的岗位结构有什么冲击以及一个普通开发者现在能做点什么。我会结合自己在一个内部项目里做的 Agent 优先改造实验尽量把抽象的行业判断落到具体的接口、文档、报错和验证流程上。如果你最近也在纠结“AI 会不会抢走开发者的饭碗”这类问题这篇应该能给你一个比“会/不会”更有用的答案。1. “第一客户是 Agent”那场对谈里最值得拆解的一组判断1.1 对谈里真正让我坐不住的那句话“第一客户”这个词在软件行业里从来不是虚的。做产品的人都知道你的第一客户是谁决定了你所有设计决策的方向。过去二十年绝大多数软件的第一客户是人网站的访客、App 的用户、后台的管理员。于是大家拼命优化页面交互、按钮位置、加载速度、视觉层级所有资源都往“让人看得懂、用得顺”这个方向倾斜。对谈里的判断是这个前提正在松动。当一个 AI Agent 能自主规划任务、调用工具、根据反馈修正行为时它替人完成了大量原本必须由人手点击、输入、切换页面的操作。它要用的软件就不再是那套漂亮的页面而是它能读懂的接口和数据结构。软件行业过去积累的很多设计原则服务的对象其实是“人类用户”一旦客户换成 Agent这套原则的适用性就要重新打问号。这句判断真正让人坐不住的地方在于它不是说 Agent 只是“多了一个用户”而是说 Agent 会成为“第一位客户”。也就是设计优先级上你的系统首先得让 Agent 好用然后才轮到人类。这个顺序一旦确立很多团队的研发资源分配、招聘标准、技术选型都会跟着变。1.2 为什么“第一客户”不是人类这个判断的推导链条我把对谈里的推导整理成了一条链条理解之后你大概率也会认同它并不激进大模型已经演化出很强的工具调用能力Agent 可以像人一样打开网页、查询接口、发送请求、解析结果。大量原本需要人亲自动手的事务正在变成“告诉 Agent 目标Agent 自己执行”。订机票、拉报表、整理会议纪要、跨系统对账都在这条范围里。要让 Agent 把事情办成软件必须向它提供稳定、清晰、机器可解析的接口。模糊的页面文案、靠视觉暗示的交互Agent 根本消费不了。一旦某个系统每天被成千上万个 Agent 调用而人类只负责例外处理那这个系统真正意义上的“日常使用者”就是 Agent。从经济逻辑看一个人的注意力只能服务一个线程但一个人可以同时监督一批 Agent。这意味着“Agent 可调用的软件服务”会快速成为一种大规模消耗的基础设施。链条走到最后一步结论就变得非常现实不是所有软件明天就要全面转向 Agent 优先但所有面向未来的平台型软件都必须把“Agent 能不能顺利接入”当作第一等的设计约束来考虑。一个值得记住的判断第一客户变了设计约束就会跟着变。你不用先说服自己“Agent 已经全面接管”只要承认“越来越多程序化任务会被 Agent 代劳”后面的很多推论就顺理成章了。2. 从“给人用”到“给 Agent 用”软件形态发生的三层变化2.1 第一层变化UI 的权重被重新分配我不是想说 UI 会消失恰恰相反最终面向人的界面仍然重要。但“界面”这个词的内涵在变过去它指的是人机交互的视觉层未来它更多指的是机器与机器之间的契约层。API、CLI、函数调用签名、事件回调这些东西会取代按钮和表单成为软件真正的主干道。拿我自己的团队来说过去做后台功能第一反应是画页面原型讨论按钮放哪、表格怎么排列、筛选项怎么设计。现在做一个新模块大家先讨论的是这个能力暴露成什么接口、参数怎么定义、返回什么结构、Agent 拿到这个结构能不能直接往后走。页面反而变成辅助人类做监督、做确认、处理异常的工具UI 的工程投入并没有消失但它在整个系统里的权重确实在往下调。对开发者而言这意味着你从前最熟悉的“把数据渲染成好看的界面”那一套正在让位给“把能力设计成清晰的契约”那一套。后者在很长一段时间里被当成二等公民现在它的地位在快速上升。2.2 第二层变化结构化数据与语义清晰度变成产品功能Agent 理解软件靠的是接口描述、字段定义、文档和示例。一个字段叫amount到底是分还是元单位字段在哪里一个状态枚举只有0、1、2还是带上了人能看懂的标签描述一个筛选参数是start_date还是date_from这些细节对人来说可能影响不大对 Agent 来说却是生死攸关的信息。我在改造系统时有一个体会以前给接口写文档会默认读者是有经验的工程师很多“不言自明”的东西就不写了。但 Agent 是一个极其严谨的“实习生”它没有行业默契每一个字段都需要明确的语义。把字段类型、枚举范围、时间时区、数值单位、参数边界写清楚这不是文档负担而是实实在在的产品功能。举一个特别小的例子。我们有一个接口返回销售数据原先字段写成{ date: 2025-01-15, sales: 15230.5 }看起来没毛病。但 Agent 调用时会有无数种理解偏差sales是订单额还是回款额日期是下单日期还是发货日期货币单位是什么后来我们把结构改成显式声明{ record_type: paid_amount, currency: CNY, date: { value: 2025-01-15, calendar: gregorian, timezone: Asia/Shanghai }, amount: { value: 15230.5, precision: cents, decimal_places: 2 } }人看得有点繁琐但 Agent 几乎不会再产生歧义。这种“为机器把话说清楚”的设计就是 Agent 优先时代的产品能力。2.3 第三层变化报错和可恢复性成为接口设计的一等公民人看到系统报错可以凭经验判断是哪里出了问题甚至能容忍“系统繁忙请稍后再试”这种模糊信息。Agent 不行。Agent 面对报错时唯一的处理方式是解析错误内容然后决定是重试、换一种调用方式还是彻底放弃把任务交回给人。这意味着错误信息必须同时具备两种性质人能读懂机器能处理。光有一句“参数错误”是不够的最好包含错误码、导致错误的具体字段、建议的修正动作以及重试时机。我们最后把错误响应的统一格式定成了这样{ error: { code: RATE_LIMIT_EXCEEDED, message: 请求频率超限请在 60 秒后重试。, retry_after: 60, request_id: a3f8-4d2e-9c1b, suggestion: 降低请求频率或等待 retry_after 秒后再发起调用。 } }为什么这么设计第一code是稳定机器可读的枚举Agent 可以根据枚举走固定的处理分支第二retry_after给了重试策略一个明确参数不用 Agent 瞎猜第三request_id让出问题时能回溯到完整调用链。这些字段里没有一个是给页面用户准备的但它们大幅提高了 Agent 自主完成任务的成功率。在 Agent 优先的语境下接口的幂等性也变得重要。Agent 的执行过程经常被打断、超时、重试如果同一笔操作被执行两次就产生两笔订单系统会越跑越乱。设计成幂等接口、让重试不产生副作用属于这个时代的基本功但很多传统系统完全没考虑过。3. 软件业还剩多少人的位置岗位被压缩与被放大的真实边界3.1 被压缩的岗位规律性、纯执行类工作先说实话被压缩的部分确实存在。我身边技术团队里过去需要三个初级工程师维护的 CRUD 后台现在一个人加一套 Agent 流水线基本能顶住。重复性很强的 SQL 查询、样板式的接口封装、简单的单元测试、固定的页面组件拼装这些工作的共同特征是规则明确、输入输出边界清楚、有大量历史样本可以学习。AI 对这种工作的替代效率是很高的。不只是写代码的岗位。软件测试里最机械的“点点点”回归、运营侧固定的数据提取、售后侧常见的“配置错了怎么改”类问答也在被 Agent 逐步吸收。这些岗位的共同特点是过去靠“熟能生巧”积累的经验现在可以被大模型快速复现。3.2 被放大的岗位需求判断、评测与兜底验证被压缩的另一面是一批岗位的价值在提高。最明显的是评测相关的工作Agent 好不好用、系统改造有没有达到预期、某个 prompt 调整是变好还是变坏这些都需要人去设计评测集、分析失败案例、判断改进方向。我观察到不少团队开始出现“评测工程师”这类角色他们不写核心业务代码但负责定义“什么是正确”这很可能是未来软件团队里最重要的岗位之一。需求判断和架构决策同样在升值。Agent 能写出代码但“到底做这个功能还是那个功能”“这个需求背后的业务方真正要的是什么”“这套系统三年后怎么演进”这些判断没有一个能靠统计规律得到。它们依赖的是对业务的理解、对技术边界的把握以及对模糊信息的结构化能力。还有一个容易被忽略的岗位价值点兜底验证。Agent 的产出不是永远可靠特别是涉及多系统联动、权限边界和历史包袱时最终拍板的人必须能识别输出里的隐性问题。“看代码知道哪里会出事”的经验型工程师在这个时代反而更稀缺。3.3 一个更现实的判断不是“AI 替代所有人”而是“AI 更少的人”我倾向于把当前的变化类比成从“面向过程的编程”到“面向对象的编程”的转变。它没有让程序员失业而是改变了对程序员的能力要求——懂得抽象、懂得模块设计的人价值和地位显著上升只会按模板堆代码的人空间被压缩。未来的软件团队很可能更接近这种形态人数更少但每个人都承担更大的判断责任。一个高级工程师配上几个 Agent能覆盖过去一整个小组的工作量前提是他要会拆解任务、设计接口、验证输出。如果只会“接需求、写代码、提测”确实会越来越被动如果能做到“定义边界、制定标准、验证质量”你的位置不但不会消失反而会因为杠杆效应变得更重要。工作类型被 AI 压缩的典型场景被 AI 放大的相关技能编码实现样板 CRUD、常规 SQL、简单组件拼装系统设计、接口契约设计、重构决策测试验证固定用例回归、机械点击测试评测集设计、失败分析、生成式测试需求分析常规信息搜集、文档整理需求拆解、模糊目标澄清、验收标准定义运维支持常见问题答复、标准配置修改异常归因、跨系统排查、预案设计4. 我把一个内部工具改造成 Agent 优先后的完整复盘4.1 改造背景一个每天被问几十次的报表系统这套系统是我所在团队维护的一个内部报表平台姑且叫它“某内部报表系统”。它的痛点是典型的传统软件模式数据都在后台但业务方拿数据必须靠人去页面里点。每周都有同事在群里问“帮我拉一下上周各区域的回款数据”“这个月的客诉分布给我导一份”。负责的同学每次都要登录系统、切换层层筛选、导出表格、发到群里。后来我们做了个决定把这个“人去点页面”的过程改成“Agent 去调接口”的过程。目标不是把页面做得更好看而是让数据获取这件事不再需要人在电脑前等着。这个决定在当时看起来有点超前但几周之后效果远超预期。4.2 具体改了什么从页面导向到接口导向改造的路径并不复杂核心就三件事。第一把每个标准报表定义成一个稳定的只读接口。每个接口都有唯一的report_id、明确可枚举的参数列表、固定的返回结构。参数校验失败时返回结构化错误码而不是随手抛一个通用异常。第二为这些接口写了一份“Agent 优先”的说明文档。每份文档里包含接口用途的一句话说明、参数含义及可选范围、返回字段的类型和业务口径、常见调用失败的示例。我们不再假设调用者已经懂业务口径而是把所有“老员工才知道的经验”写进文档。第三把输出标准化。所有接口统一支持 JSON 和 CSV 两种格式日期字段统一使用带时区标记的格式数值字段统一声明单位。这样 Agent 不管拿数据去生成报告、做图表还是喂给下游模型都不需要再做额外猜测。4.3 实测中 Agent 能干的和干不了的改造上线后我们开始让 Agent 直接面对真实业务提问。效果最明显的是三类任务一类是“把某两个时段的数据拉出来对比”Agent 可以自己理解参数、构造请求、处理返回结果一类是“按片区汇总最近三个月的回款趋势”它能把多个接口的返回结果拼在一起做简单分析还有一类是定时报表推送每天固定时间抓取数据生成摘要完全自动。Agent 搞不定的也有典型模式。第一个是业务口径含糊的问题“活跃用户”在不同部门有不同定义Agent 选了其中一种但没有跟提问者确认结果被人指出数据不对。第二个是跨系统对账数据散落在多个系统里而系统之间的关联键历史上有过迁移Agent 缺少这套“隐性知识”自己拼出的结果经常对不上。第三个是需要创造性的可视化设计它能做基础图表但做不到“根据数据特点选择最有说服力的呈现方式”。这些失败案例非常重要因为它们划出了“人的位置”需要业务判断、隐含知识、创造力的地方Agent 短期仍需要人在回路里兜底。4.4 这次改造踩过的三个坑第一个坑在报错信息里。最初我们延续了面向人的报错习惯诸如“输入有误”“系统异常请联系管理员”。Agent 拿到这种信息完全无法推进只能反复尝试或直接放弃。后来我们把所有错误信息重写成“错误码 可读消息 修正建议 重试参数”效果立竿见影Agent 的首次成功率整整提高了一个档次。第二个坑是接口变动太随意。改造初期字段名、参数结构经常调整每次调整都会让跑在系统上方的 Agent 静默失败。后来我们立了规矩公开接口一旦定稿至少锁定一个完整版本任何破坏性变更都走版本号升级并把旧版本保留至少 12 个月。这个规范让人难受但它保护了所有依赖方包括人类和 Agent。第三个坑是上下文塞得太满。一开始为了让 Agent 充分理解系统我们把所有接口文档、数据字典、示例一股脑扔进提示词结果 Agent 的推理表现反而明显变差。后来改用“按需加载”的方式只给 Agent 当前任务最需要的接口摘要详细的字段说明通过工具在运行中去查询。上下文精简之后准确率明显回升这也是很多人做 Agent 时容易忽视的一个训练代价问题。5. 普通开发者现在该练的三件事可调用性、评测能力和判断力5.1 把手头服务的“可调用性”当核心指标不管你现在维护的是内部后台、开放平台还是移动端的后端服务都值得把“可调用性”当成一个一等公民指标来对待。什么是可调用性就是别的程序能不能稳定地、无歧义地、低成本地接入你的服务。具体来说接口要有版本号字段要有完整 schema错误要有稳定枚举操作要有幂等语义文档要能让一个没有背景知识的调用方快速上手。这跟“代码写得好不好”是两码事。我见过很多团队的接口人和人用着没问题但因为文档缺失、错误信息含糊、契约不稳定Agent 就是接不进去。把这些补齐短期看是“文档工作”长期看是在为你自己的系统进入 Agent 生态铺路。你手上几乎每个服务都值得这样过一遍假设调用者是一个没见过你的系统的新同事它能靠你的接口描述和报错信息独立完成任务吗5.2 学会给 Agent 建评测集这是我认为未来两三年最值得掌握的工程能力。传统的单元测试测的是“同一个输入有没有同一个输出”Agent 的评测则要测“面对一批开放任务Agent 能不能在允许范围内给出可接受的结果”。方法并不神秘准备一批代表性的业务问题作为黄金样本每条标注好正确的处理结果或验收标准然后定期跑一遍统计通过率、观察失败模式。不需要一开始就做得很大二三十条覆盖典型场景的样本就足以发现问题。我自己就是从一个小样本集开始的跑了不到两周就发现了好几个文档没写清楚的地方。建立评测集之后你改 prompt、调接口、换模型都会有自己的“回归测试”不会越改越乱。这个能力现在是稀缺的。5.3 把判断力当真正的护城河最后说一个听起来有点虚、但最能决定岗位价值的东西判断力。AI 能生成大量方案但“哪个方案值得做”“这个需求背后的真实意图是什么”“这个 Agent 输出到底对不对”仍然需要人来拍板。判断力来自哪里来自你对业务逻辑的理解、对历史背景的了解、对边界情况的敏感性以及长期积累的“做砸过”的经验。说白了软件行业给人类留下的位置不在“做”的那一层而在“决定做什么、验证做得对不对”的那一层。这不是什么安慰话它意味着你要主动调整自己的成长方向多参与需求前期讨论多写验收标准多复盘线上故障多思考系统边界。这些工作不像写代码那样有明确的完成状态但它们非常难被 Agent 取代。如果你现在就开始做这三件事哪怕只是先把一个服务整理成“Agent 友好”的状态几个月后回头看你对所谓“AI 焦虑”的感受会和今天完全不一样。这次改造对我自己最大的影响是工作重心的变化。以前我大量的时间花在写接口、调样式、处理琐碎重复逻辑上现在这些事有很大一部分可以交给 Agent 和代码生成工具完成。省下来的时间被我更多地用在了需求确认、边界讨论和验收上。最开始有点不习惯总觉得不亲手写代码心里不踏实但几周之后我意识到真正卡住项目进度的从来不是代码量而是需求没想清楚、接口没设计对、结果没人敢拍板。软件再怎么变解决这些问题的能力依然是人的位置所在。