★ FEATURED ARTICLE 1. 从写代码到写能写代码的东西交付物到底变了什么第一次听到Agent 能开发 Agent这个说法我脑子里冒出来的不是兴奋而是一个很具体的困惑如果工具本身能造工具那我每天交付的那些东西到底还剩多少价值这个问题我在过去一年里反复想过也跟不少做工程、做产品的朋友聊过发现大家的焦虑点其实高度一致——不是怕被替代而是怕自己交付的东西突然变得不值钱了。先把概念说清楚。这里说的 Agent指的是能自主感知环境、做决策、调用工具、执行多步任务并拿到结果的智能体。而Agent 能开发 Agent指的是用一套智能体框架去生成、配置、调试另一个智能体甚至让它自己完成从需求理解到部署上线的部分环节。这件事在工程上已经不是科幻很多团队已经在做类似的事情用一个编排型 Agent去生成执行型 Agent的配置、提示词、工具绑定和测试用例。那交付物变了吗变了而且变得很彻底。以前我们交付的是一段能跑的代码、一个能用的功能、一个上线的服务。现在越来越多的时候我们交付的是一套能自己长出功能的机制——包括提示词模板、工具注册表、评测集、回滚策略、成本护栏。代码只是这套机制的一个产物而不是终点。我打个比方。以前你是木匠交付的是一把椅子。现在你是造木匠工作台的人交付的是一套能让木匠快速做出各种椅子的工作台外加一套质检标准。椅子还是要做但你的核心价值转移到了工作台的设计和质检标准上。这个转移才是Agent 开发 Agent这件事真正让人不安又兴奋的地方。所以这篇文章我想聊的不是怎么用某个框架搭一个 Agent这种教程级内容而是站在一个实际交付过多个智能体项目的人的角度把这件事拆开交付物到底变成了什么、哪些环节真的能自动化、哪些环节自动化之后反而更危险、以及我们这些从业者应该把精力重新押在哪里。如果你正在做智能体相关的项目或者正在焦虑自己的技能会不会过时这篇应该能给你一些具体的参照。2. 拆开Agent 开发 Agent这句话哪一层真的在自动哪一层只是看起来自动2.1 三个层次生成配置、生成代码、生成评测很多人把Agent 开发 Agent当成一个整体其实它至少分三层每层的成熟度天差地别。第一层是生成配置。这是目前最成熟的一层。你给一个编排型 Agent 一段自然语言描述它输出一个执行型 Agent 的配置文件系统提示词、可用工具列表、参数约束、输出格式。这一层之所以成熟是因为配置本身是结构化的、可校验的生成错了很容易发现改起来成本也低。第二层是生成代码。让 Agent 写出工具函数、数据处理逻辑、API 调用封装。这一层半成熟。简单的、模式化的代码它写得又快又好但一旦涉及复杂的业务状态、边界条件、并发处理它就开始自信地犯错。我见过太多看起来能跑、一上生产就崩的生成代码。第三层是生成评测。让 Agent 自己设计测试用例、自己判断输出好坏、自己决定要不要回滚。这一层最不成熟也最危险。因为评测标准本身如果由被评测的对象来定就等于让考生自己出卷子自己批改很容易出现自我感觉良好的系统性偏差。把这三层分清楚很多焦虑就能落地了。真正在自动化的主要是第一层和部分第二层。第三层目前更多是辅助生成候选评测集人来定最终标准。谁要是跟你说他的系统能全自动完成三层你基本可以判断他在夸大。2.2 为什么生成配置这一层最先跑通这里有个很实在的工程原因配置是有 schema 的。有 schema 就意味着有校验、有类型、有必填项、有取值范围。Agent 生成的东西只要过不了 schema 校验就直接被打回重来不需要人去逐行读。这种机器可判定对错的任务天然适合交给 Agent 去做。而代码和评测缺的恰恰是这个机器可判定对错的闭环。代码能不能跑是一回事跑得对不对是另一回事评测用例合不合理更是没有客观标准。所以自动化程度自然就低。我在实际项目里的做法是把能结构化的部分尽量结构化把不能结构化的部分明确标成需要人审。比如工具调用的参数我会定义成严格的 JSON Schema而这个回答是否符合业务语气这种判断我会明确交给人工抽检不让 Agent 自己拍板。这个边界划清楚之后整个系统的稳定性会好很多。2.3 一个容易被忽略的事实Agent 生成 Agent瓶颈往往不在生成而在验证大部分人做这类项目第一反应是优化生成环节——换个更强的模型、调更好的提示词、加更多的示例。但实际跑下来你会发现生成从来不是瓶颈验证才是。生成一个 Agent 配置可能只要几秒但你要确认这个配置在真实场景下不出问题可能要跑几十个用例、花几十分钟甚至几天。生成的成本趋近于零验证的成本却居高不下。这就导致一个反直觉的结论当生成变得廉价验证就成了新的稀缺资源。这个结论直接决定了交付物的形态。你交付的不应该只是能生成 Agent 的系统而应该是能生成 Agent 并且能高效验证 Agent 的系统。后者才是真正有价值的部分也是大部分团队做得最薄弱的部分。3. 交付物清单重写从功能列表到能力生产线3.1 传统交付物 vs 智能体时代的交付物我把两种交付物列个表对比一下这样看得更清楚。维度传统软件交付Agent 开发 Agent 场景下的交付核心产物可运行的功能/服务能生成功能的配置与流水线主要资产代码库提示词库、工具注册表、评测集质量保证单元测试、集成测试评测集 人工抽检 回滚机制变更成本改代码、重新发布改配置、重新生成、灰度验证关键角色开发、测试、运维编排设计、评测设计、成本控制失败模式崩溃、报错静默错误、自信地胡说、成本失控这张表里最值得盯的是最后一行。传统软件的失败通常是显性的——崩了、报错了、页面白了你立刻知道。而智能体系统的失败往往是隐性的——它没报错它给了你一个看起来很像那么回事的答案但答案是错的。这种静默失败才是交付这类系统时最大的坑。3.2 提示词库为什么成了核心资产在传统项目里提示词这种东西根本不算资产顶多算个配置项。但在 Agent 开发 Agent 的场景下提示词库的地位直线上升因为它直接决定了生成出来的 Agent 的行为边界。我现在的习惯是把提示词当成代码来管理。具体来说每个提示词模板都有版本号、有变更记录、有对应的评测用例、有回滚点。改一个提示词跟改一段核心代码一样要走评审、要跑评测、要灰度。听起来很重但踩过坑之后你会发现这点重量完全值得。为什么因为提示词的一个小改动可能导致生成出来的 Agent 在某个边缘场景下行为完全跑偏。而这种跑偏在常规测试里根本测不出来只有靠专门的评测集才能发现。没有版本管理和评测配套的提示词库就是一个随时会炸的黑盒。3.3 工具注册表被低估的交付核心还有一个经常被忽略的交付物是工具注册表。Agent 要干活就得调用工具——查数据库、调接口、读写文件、发消息。这些工具怎么注册、怎么描述、怎么约束参数、怎么处理失败直接决定了 Agent 的能力上限和稳定性。我见过不少项目Agent 的大脑做得很精致但工具层一塌糊涂工具描述含糊、参数没有约束、失败没有重试、超时没有处理。结果就是 Agent 经常调错工具、传错参数、卡在半路。这时候你再怎么优化提示词都没用因为问题出在工具层。所以我现在交付这类系统工具注册表是跟提示词库并列的一等公民。每个工具都有清晰的描述、严格的参数 schema、明确的失败语义和重试策略。这部分做扎实了Agent 的稳定性会有质的提升。4. 验证才是新的主战场评测集、护栏与成本控制4.1 评测集怎么建才不是自欺欺人评测集是这类项目里最容易被做假的部分。很多团队的评测集是这么建的找几个典型问题跑一遍看着差不多就过了。这种评测集基本没有价值因为它既覆盖不了边缘场景也没有客观的判定标准。我的做法是分三层建评测集。第一层是冒烟集几十个最基础的用例每次改动都跑确保没有低级错误。第二层是回归集几百个覆盖主要业务场景的用例每次发版前跑。第三层是对抗集专门收集那些曾经出过问题的、刁钻的、边缘的用例只增不减。对抗集是最有价值的因为它记录的是真实的失败。每次线上发现一个 Agent 的坏 case我就把它加进对抗集确保以后不会再犯。这个集子会越滚越大但它带来的稳定性提升是实打实的。判定标准这块能自动判定的尽量自动判定比如格式、字段、数值范围不能自动判定的明确标注人工判定并且规定抽检比例。最忌讳的是让 Agent 自己判定自己那等于没有判定。4.2 护栏不是限制能力而是划定安全边界护栏这个词听起来像是给 Agent 上枷锁其实不是。护栏的作用是让 Agent 在安全的范围内自由发挥而不是让它到处乱撞。我常用的护栏有几类。第一类是输入护栏过滤掉明显不合理的请求避免 Agent 在无意义的输入上浪费算力和成本。第二类是输出护栏检查生成的内容是否符合格式要求、是否包含不该出现的信息。第三类是行为护栏限制 Agent 能调用的工具范围、能访问的数据范围、能执行的操作类型。行为护栏尤其重要。一个能自主调用工具的 Agent如果没有行为护栏理论上可以做出任何它被授权的事情。所以授权范围一定要收窄到刚好够用而不是图省事全开。4.3 成本控制被严重低估的交付指标智能体系统的成本结构跟传统软件完全不同。传统软件的成本主要是固定的服务器开销而智能体系统的成本跟调用量、token 消耗、工具调用次数强相关波动极大。我踩过的最大的坑就是成本失控。一个看起来设计得很优雅的 Agent因为陷入了某种循环调用一夜之间烧掉了远超预算的额度。从那以后成本控制就成了我交付这类系统的硬性指标。具体做法包括给每个 Agent 设置单次任务的 token 上限和工具调用次数上限设置日/月总额度告警对高频调用做缓存对复杂任务做分级处理简单的用便宜模型复杂的才用贵模型。这些措施加起来能把成本压到可控范围。提示成本控制一定要在系统设计阶段就考虑而不是上线之后再补。事后加限制往往要改动核心逻辑成本高得多。5. 从业者的能力迁移哪些技能在贬值哪些在升值5.1 正在贬值的纯执行型技能说句实在话那些照着文档写代码按需求实现功能的纯执行型技能确实在贬值。因为这类工作的本质是把明确的输入转换成明确的输出而这正是 Agent 最擅长的。但注意贬值不等于消失。这类技能的需求量还在只是单价在下降竞争在加剧。如果你现在的核心竞争力就是能快速实现明确需求那确实需要警惕。5.2 正在升值的定义问题、设计评测、控制边界升值的技能集中在三个方向。第一是定义问题的能力——把模糊的业务需求翻译成 Agent 能理解、能执行、能验证的任务描述。这件事看起来简单实际上极难因为它要求你既懂业务又懂技术还要能预判各种边界情况。第二是设计评测的能力——知道该测什么、怎么测、测到什么程度算过关。这是保证系统质量的核心也是目前最稀缺的能力。第三是控制边界的能力——知道该给 Agent 多少权限、该在哪里设护栏、该在什么时候让人介入。这需要你对业务风险有清晰的判断。这三项能力的共同点是它们都涉及判断而不是执行。判断这件事目前还是人的主场。5.3 一个具体的转型路径如果你现在做的是偏执行的开发工作想往这个方向转我给一条具体的路径。先从你手头的一个小功能开始试着把它拆成配置 工具 评测三部分。配置部分用提示词描述清楚工具部分定义好输入输出评测部分写几个用例。然后尝试用 Agent 去生成这个配置看看生成的结果跟你手写的差多少。这个过程会让你直观地感受到哪些部分 Agent 做得比你好哪些部分它做得比你差。做得比你好的部分就是你该放手的地方做得比你差的部分就是你该深耕的地方。反复做几次你的能力重心自然就迁移过去了。6. 一个真实的踩坑复盘当生成速度超过验证速度6.1 事情是怎么发生的我参与过一个内部工具项目目标是让一个编排型 Agent 自动生成一批数据处理 Agent。刚开始一切顺利生成速度飞快一天能产出几十个可用的配置。团队很兴奋觉得效率提升了十倍。问题出在第二周。我们开始把这些生成的 Agent 接入真实数据流结果发现有一批 Agent 在处理特定格式的数据时会静默出错——不报错但结果不对。更麻烦的是因为生成得太快我们根本不知道哪些 Agent 有问题只能一个个排查。6.2 排查链路排查过程大致是这样的。第一步先确认问题范围把所有生成的 Agent 按数据格式分类发现出错集中在某几种边缘格式上。第二步对比出错 Agent 和正常 Agent 的配置差异发现出错的那些在提示词里对边缘格式的描述含糊。第三步回溯生成过程发现编排 Agent 在生成这些配置时因为原始需求描述里没提边缘格式它就合理推测了一个处理方式而这个推测是错的。根因很清楚生成环节缺少对边缘场景的显式约束而验证环节又没能覆盖这些场景。两个环节的缺口叠加导致了静默错误。6.3 修复方案与后续改进修复分两部分。短期是把出错的 Agent 挑出来重新生成并在需求描述里补上边缘格式的明确说明。长期是建立一套生成即验证的机制每个生成的 Agent 必须通过一组标准评测用例才能进入下一环节评测用例里专门包含各种边缘格式。这次踩坑给我最大的教训是生成速度越快验证能力越要跟上否则快就是灾难。一个能一天生成一百个 Agent 但没有验证能力的系统比一个一天只能生成十个但有完整验证的系统危险得多。因为前者会让你在不知不觉中积累大量隐患。7. 我现在的交付习惯几条踩过坑之后定下来的规矩做了几个这类项目之后我慢慢形成了几条自己的规矩分享出来供参考。第一条任何自动生成的东西都必须有对应的验证手段。没有验证的自动化就是在批量制造技术债。这条规矩帮我挡掉了很多看起来很美好的方案。第二条提示词、工具、评测集三者必须同步演进。改了提示词就要更新评测集加了工具就要补对应的测试用例。三者脱节是很多问题的根源。第三条成本护栏和权限护栏必须在设计阶段就定好。上线之后再补代价大得多而且往往补不干净。第四条永远保留人工介入的通道。不管 Agent 多智能关键决策点上一定要有人能接管。这不是不信任技术而是对业务负责。第五条把能生成和能交付分开看。能生成只是第一步能稳定交付才是目标。很多团队卡在第一步就以为快成功了其实真正的硬仗在第二步。这几条规矩听起来朴素但每一条背后都有具体的踩坑经历。如果你正在做类似的项目希望这些经验能帮你少走点弯路。这个领域变化很快但有些底层的工程原则是不变的——验证、边界、成本、人工兜底这些东西不会因为模型变强就消失反而会变得越来越重要。
阅读完成 · 觉得有帮助？
