这问题我至少被问了十回，最近一次是评审会上，一位后端老哥看着我的 Agent 方案，问得直白："你这 Agent 能干的活，哪个不是数据库查一下、接口调一下、if-else 判一下就能完事的？为什么一定要做 Agent？"
我当时没法三言两语说完，因为这个问题表面是质疑技术选型，背后其实是两套做事逻辑的碰撞。写这篇文章就是想把这个事彻底讲明白：硬编码确实"能"干很多事，但"能"和"值得"、"可维护"、"抗变化"是四件事。如果你也正在纠结要不要上一个 Agent 方案，或者被评审过 "为什么不做个规则引擎就行"，这篇文章应该能帮你想清楚。
1. 硬编码到底"能"在哪里：承认它站立在确定性世界
硬编码最大的本事，是面对有限状态空间时的稳定输出。它像一盘提前排练好的舞蹈，每一步都写在脚本里，输入和输出永远一一对应。
1.1 硬编码的核心优势没有被夸大
处理已知规则，硬编码开箱即用。比如一个自动化工单流转系统，状态机里有"待分配、处理中、已解决、已关闭"四种状态，迁移条件是角色和状态组全。用状态表加几个方法就能跑，线上稳定运行三五年不需要人管。
这类功能硬编码的优势非常硬：
- 行为完全可预期，A 输入必然得 B 输出，不会给出超纲结果。
- 运行成本极低，几个函数调用，不依赖外部接口。
- 调试成本低，出问题看堆栈、看日志，几分钟定位。
- 审计容易，每一条执行路径都写在代码里，人可以直接审。
我见过最极致的硬编码系统，是一个内部自动化报表工具，用三千多行配置把上百张报表的上游表、字段映射、调度依赖全写死，跑了好几年，效果不错。团队甚至说"这就是我们的规则引擎，改起来麻烦但稳定"。这种评价不冤，在确定性世界里，硬编码就是最优解。
1.2 但当"能"的标准被放宽，破绽就出现了
问题是，现实业务很少待在确定性世界里。我拿一个场景问你：用户提交一条工单说"打印机卡纸了，连着两次，第二次是在凌晨打印机没有任务时发生的"，你让硬编码怎么处理？
按关键词分类，规则写得再细，落到"凌晨没有任务时卡纸"这种语义上，要么拆出几十个组合条件，要么漏判。这不是硬编码不勤奋，而是它要穷举的状态空间已经开始发散。再往后，需求方又说"顺便看看卡纸次数和保修期限有没有关系，写个分析放报表里"，硬编码又要加表、加字段、加逻辑。
到这里你发现了没有：硬编码的"能"建立在需求完全确定、状态空间有限的假设上。可真实业务里，输入是自然语言、状态是长尾分布、需求是动态变化的。硬编码就像一个只会照谱弹琴的乐手——谱子它会弹，但你让它即兴变奏，它就卡壳了。
2. Agent 真正的增量：不是新能力，是决策权的让渡
很多技术人对 Agent 的第一反应是"不就是一个大模型包装器嘛，把用户的话丢给大模型，然后取回文本回答"。这个理解太浅了。Agent 和大模型单次调用的差别，不在于"懂了多少知识"，而在于它拿到了一个东西：运行时决策权。
2.1 决策权让渡：从"人写死路径"到"机器选路径"
传统开发模型是"人决定逻辑，代码执行逻辑"。你写一个if action == "refund": refund_process()，哪个分支干什么，是人提前定的。Agent 的逻辑不是这样，它拿到目标之后，自己决定先调哪个工具、参数怎么填、条件满不满足、要不要换一条路，整个过程没人提前画流程图。
我举个例子：任务"查一下上季度华东区退货率最高的三个品类，并写一份分析摘要"。硬编码要写多少行？先查时间范围，再关联订单表、退款表，按地区和品类聚合，排序取前三，最后拼摘要——每一步都要人先想清楚。Agent 只需要拿到工具清单（数据库查询工具、报表生成工具、文档工具），它自己编排调用顺序，中间发现某个类别数据缺失，还会临时决定补充一次关联查询。
这就是决策权让渡。硬编码把"怎么干"写死在代码里，Agent 把"怎么干"变成运行时一步步推理出来的选择。
2.2 Agent 不是"查表器"，它是"边想边干"的执行者
我比较喜欢用"解释器"来类比：传统程序是编译好的二进制，逻辑不变；Agent 更像解释执行，每一步都在读最新状态，然后产出下一步操作。它维持着一个循环——收集信息、评估现状、决定动作、执行动作、观察结果、再评估。这个循环本身就是它区别于普通模型调用的核心架构。
这个循环带来一个副产品：环境适应能力。硬编码遇到预料外输入时只能报错，Agent 遇到预料外输入时，只要能理解，就能尝试转变策略。
举个例子，某内部系统本来用硬编码解析部门代号，结果新来的供应商传了全称而不是代号，解析就断了。后来换成 Agent，工具定义不变，模型自己发现字段对不上，会自动调别名表来查，多一步操作就把问题消化了。硬编码要改代码发布，Agent 不用改代码，它只是"多做了一步推理"。
2.3 交互范式的变化：从"接口"到"目标"
硬编码时代，使用者要和系统对话必须走接口语言，什么叫"查一下上季度华东区退货率最高的三个品类并写摘要"？你得拆成接口参数、权限校验、格式化输出。Agent 时代，人只描述目标，Agent 负责把目标翻译成工具调用序列。
这背后的实体不是"更聪明的代码"，而是"意图理解 + 拆解 + 工具调度 + 反馈验证"这四个环节的组合。硬编码只覆盖了"调度"这个环节，剩下的三个环节它是空白。所以说 Agent 不是抢硬编码的活，而是补上了硬编码缺的那三块拼图。
入行不久的朋友容易卡在一个点上：工具执行不还是要写硬编码吗？对，工具层的确定性部分（比如查数据库、发请求）当然要写代码，Agent 管的是"决策层"——工具调度和路径选择。前者是车间里的机床，后者是看着图纸决定先车哪个零件、怎么车的老师傅。
3. 真实场景里"撑不住"的信号：三条硬编码防线被击穿的现场
讲道理有点务虚，我拿三个实战场景说事。这些场景我都在真实项目里遇过，硬编码单子都能跑，但跑到后期，维护成本开始吞噬收益，团队最终都被迫转到了 Agent 架构。
3.1 场景一：流程编排的蝴蝶效应，规则之间互相踩脚
某团队做了一个多系统数据同步任务，最初十几条规则，硬编码编排绰绰有余。后来加了新数据源、新清洗逻辑、新重试机制，规则涨到五十多条，问题陆续出现：A 规则的正常输出会被 B 规则当成异常输入，C 规则为重试设的等待时间导致 D 规则超时，规则之间的依赖像一团毛线球。
改一条规则，要重新过一遍所有其他规则。团队最后用 Agent 重写，把每个数据源和一个校验工具绑定，Agent 在编排层面做动态调度：数据源异常就自动换校验策略，超时自动调优先级，规则冲突由模型上下文感知来做仲裁。有人会问，这不还是状态机吗？区别在于，状态机要先穷举规则冲突的可能，Agent 是在运行时碰到冲突再处理。面对"规则组合爆炸"这类问题，先穷举那一条路已经走死了。
3.2 场景二：自然语言边界，白天用得好，晚上就被"反杀"
某客服系统最初用关键词做工单分类，运营同学抱怨准确率不稳定。我观察过，典型翻车案例是这样的：用户写"我要退款，但订单是朋友帮我下的，我可以退吗"——既有"退款"关键词，又有"朋友代付"语义。硬编码这几种切法都切不顺，Feature A 关键词把 "朋友代下" 对到代付流程，但漏掉了 "退款" 条件；改规则就要以牺牲另一类准确率为代价。后来换成 Agent，分类任务交给模型阅读理解，工具层负责把结果写入工单并通知，准确率上了一个台阶，更关键的是新增分类不再需要改代码，改一句 prompt 描述就能加。
3.3 场景三：长尾异常处理，硬编码处理不完的"野路子"
系统跑久了什么都会遇到：上游数据缺字段、字段格式被悄悄改变、接口偶尔返回 weird 结构。硬编码处理长尾异常的做法是"遇到一个补一个 case"，补到最后代码堆到没法看，仍然有兜不住的新场景。
Agent 对异常场景的天然优势是能"现想现办"。有一次同步任务遇到上游字段值混入了不可见字符，硬编码的 schema 校验直接抛异常，Agent 则在工具调用后观察到了校验失败信息，自动走了"清洗工具"再重试。它没有专门为这个异常写法，但当场推理出了补救策略。这就叫"不可预编程的应变能力"。
我并不是说服大家把硬编码全扔了，工具层永远要写硬编码。但要认清：一旦你的问题域里出现了"自然语言输入"或"组合状态爆炸"或"高频的未知异常"，硬编码这条防线就撑不住了，它后面的路只有一条——加人力维护规则、加配置、加补丁。这条路是幂等上升的，迟早会到一个崖边。
4. 代价清单：为什么有人做了 Agent 又退回硬编码
我聊过几个"上了一期 Agent 又退回去"的团队，他们不是不认可技术，而是低估了代价，或者说，对 Agent 的期望管理出了问题。搞清楚这些人为什么会翻车，你才能判断自己还要不要上。
4.1 看不见的成本：请求费、延迟、调试复杂度
Agent 一次任务要跑好几轮模型调用。同样是查一个数据，硬编码一次 SQL 查询几十毫秒，Agent 要经历"理解意图→选工具→调工具→看结果→总结"，一分钟算少的。银行级客户对"秒开"的要求，Agent 目前根本满足不了，这是硬伤。
成本也好算：一个日均一万次调用的 Agent 任务，如果每次推理消耗几千 token，一个月光模型费用就是一笔不小的账。硬编码跑相同的工具调用，费用几乎为零。这还没有算上调试成本——硬编码异常能打日志，Agent 跑偏了可能要反复重放上下文，看它哪一步推理错了，调试复杂了一个量级。
4.2 确定性丢失，审计与合规迎头撞上
很多团队退回硬编码不是因为跑不通，而是因为不敢让 Agent 上线。金融、医疗、司法这类圈子，要求每一步动作都可以回放、可解释。硬编码能保证"某输入必然走某分支"，Agent 却会因为 prompt 里一个字的变化，前后走两条不同的路。你说审计官怎么验收？
这不是技术难题，而是责任边界问题。出了事，责任人是谁？写 prompt 的？写工具的？还是模型厂商？这个责任链条如果没搭好，项目大概率会被叫停。这也是为什么我建议起步阶段别选高合规要求的业务线，选个内部工具场景先跑，等责任模型打磨清楚了再扩张。
4.3 期望错配：拿砍柴刀去切葱花，自然全线失败
我见过最典型的翻车是：一个内部审批系统，逻辑明明固定得很——金额小于阈值就走 A 分支，大于阈值走 B 分支。团队非要让 Agent 来判，模型偶尔犯浑把边界案例判错，一次钱款流程走错，业务方直接炸了。这种问题换谁来都该用硬编码，本身状态空间只有两三个，Agent 的"灵活"就是负担。
拿砍柴刀去切葱花，不是刀不好，是工具和环境不匹配。很多人一听到 Agent 就兴奋，看到什么场景都往上套，结果把本来确定性很高的东西做飘了，反过来骂 Agent 不成熟。这是人的选型问题，不是技术路线问题。
5. 选型判断框架：四个问题决定你该写死，还是该上 Agent
聊到这里，可以给一套可以抄作业的判断方法了。我每次做技术选型时都会过四个问题，一套下来答案基本清晰。
5.1 问题一：状态空间是不是有限的？
问自己：满足条件的分支是不是可以穷举？如果能列到第八十个 case 还觉得能维护，硬编码没毛病；如果列到第三十个你已经不想往下写了，说明状态空间在发散，Agent 适合介入。一个辅助标准：看看最近半年需求变更，是不是有大量"加一个新 case"类的改动。如果"加 case"的频率让你怀疑人生，这个域就该让 Agent 接管决策了。
5.2 问题二：输入是不是只有结构化数据？
如果输入永远是 API 参数、DB 字段、固定格式文件，Agent 优势不大，硬编码能做得更稳。一旦输入里掺了自然语言、图片、半结构化文本，你要的是"理解"而不只是"解析"，此时硬编码会陷入字面匹配的泥潭。用词区分：解析是按模板拆，理解是按语义解。你要的是哪一个？
5.3 问题三：失败成本有多高？
这也是最关键的一道坎。Agent 的失败不是零概率，模型有幻觉、工具会误调、流程可能绕远路。如果你的场景失败一次赔用户几十万、或者要进监管流程，那硬编码再笨也是安全的。Agent 适合失败代价可控的域——比如分类分错再人工改一下、报告写歪了再改一版——这类场景容错空间大，Agent 折腾得起。
5.4 问题四：需求变动频率和变动性质是什么？
硬编码怕的不是变动频率，而是变动的"结构性质"。如果只是参数值变了，配置文件就能解决；如果是判断逻辑变了、处理策略变了，硬编码每回都要发版，Agent 改一段 prompt 就好。我常用一句话总结：参数变用配置，逻辑变用代码，策略变用 Agent——策略是什么？是"基于当前情况选择哪个逻辑"的那个上层逻辑。Agent 管的正是这一层。
5.5 落地路线图：从"工具编排"到"局部决策"再到"全局代理"
如果你判断自己该上 Agent，别一上来就铺一个大而全的平台。我见过的成功路径都是从小切口开始：
第一步，先把工具层做成标准 API，每个工具定义清晰的输入输出和错误码，这是 Agent 的地基。没有稳的工具层，Agent 就是踩在流沙上跳舞。
第二步，做"工具编排"场景，用 Agent 把多个工具的调用顺序交给模型编排，人仍然在关键节点审批。这个阶段你能摸清模型的调度能力，也能发现工具定义里的模糊地带。
第三步，收窄决策范围到单一环节，比如只让 Agent 做工单分类、只做异常检测、只做摘要生成。这一步要建评测集，至少几百条真实样本，持续跑，看准确率和回归情况。
第四步，评估通过后再扩展到多环节，逐步加回护栏——人工审核闸门、成本控制、超时熔断、上下文清理。走到这一步，你大致就算迈过了那个"硬编码早就能干"的坎了。
6. 各自的本分与边界：让 Agent 在确定性的地基上跳舞
前面讲了很多对比，最后我把双方的本分说得更直白一点。
硬编码不是"要被 Agent 淘汰的旧东西"，相反，它永远是 Agent 的地基。我在实操中最常做的一件事，不是写 Agent 的逻辑，而是把原本应由硬编码处理的稳定逻辑梳理干净：数据结构、状态机、幂等控制、审计日志、重试机制，这些都要写到最硬。Agent 的灵活性是建立在这些稳定零件之上的——它能自由选择路径，但路径上的轨道必须稳。
我见过太理想的团队，想把 Agent 做成"从零自决策"的黑盒，结果在上游数据质量不稳定的情况下，模型每一步都走在弯路里。后来大家悟了：先把能写死的都写死，把该保证的都保证，留下的决策空白才是 Agent 该补的区域。Agent 是插花的人，硬编码是那张扎实的桌子。桌子不牢，插什么花都会倒。
具体操作上有几个小技巧分享一下：
- 给 Agent 定义工具时，宁可工具多一点、描述写得长一点，也别让模型猜某个参数能不能用。我有一条经验：工具描述的清晰程度，直接决定行为可靠性，模糊 10% 的描述会导致不确定性翻倍。
- 一定要做工具调用的超时和重试策略。Agent 不会永远在正轨上，文件中转、网络波动、上游慢都可能让它卡死，必须有机制让它主动承认"这步失败了"，然后换路。
- 评测集要常驻。每次改 prompt、换模型、动工具结构，都要跑一遍回归。没有评测集的 Agent 项目，混过开发期，也会死在迭代期。
所以回答标题那个问题：为什么一定要做 Agent？因为硬编码能干的是"已知的、确定的、可穷举的活"。可现实业务里有太多"没见过的输入、没法提前写死的决策路径、不断冒出来的组合场景"，这些活硬编码确实干不了，等着你的只有无穷无尽的 case 补丁。Agent 不是把硬编码的活抢过来做，而是接手那块硬编码一直干不动的区域——那块需要临场理解、动态决策和即时应变的区域。
最后再分享一个我包里的常备方案：每上一个 Agent 功能，我都会在系统里留一个"人工接管"按钮，一键把流程切回硬编码的默认路径。这不是对 Agent 没信心，而是给自己留退路，也给业务方留安全感。很多团队就是因为没留这个后门，出事时被迫全员手动操作，这才把项目搞砸了。做个有后路的 Agent 架构，你才能在上线的每一天都睡个踏实觉。
