Codex 这么强，业务 Agent 开发还有必要吗？

一句话先讲透通用 AgentCodex、Cursor 等与业务 Agent 不是竞争关系而是两种部署形态——前者是跑在客户端的超级个体工具强在写代码、查资料、生成文档后者必须和你的应用代码一起跑在服务端实现按规则、有权限、可追责的业务闭环。企业里真正难的是后者。一、背景一个让 Agent 开发者焦虑的问题Codex 已经这么强了为什么还需要 Agent 开发——这是 2026 年每个企业 AI 团队都在被 CTO 追问的问题。OpenAI 的 Codex、Anthropic 的 Claude Code、以及各种千万 token 免费用的编程助手在写代码这件事上已经展现出接近资深工程师的水平。看起来Agent 开发这个工种似乎要被用 Agent取代了。程序员Hollis粉丝 17.2 万的 Java/大模型领域博主在这条 93 秒的短视频里给出了一个犀利的回答这些通用产品本身就是 Agent 开发做出来的。只不过它们聚焦在通用场景而企业里真正难的那部分——让 Agent 在你的业务里按规则、有权限、可追责地干活——依然是空白。这条视频信息密度极高93 秒里塞下了通用 vs 业务的分野、四个核心问题、一串工程化清单和一条自研判断标准值得逐层拆开。图 1通用 Agent 与业务 Agent 的部署形态与评价标准对比二、通用 Agent 强在哪客户端场景的超级个体视频开头承认了事实Codex 这类工具在写代码、查资料、生成文档、套模板做网页等方面确实很强。它们是跑在客户端的 Agent工作对象是用户自己的文件、代码库和浏览器——一个可控、可回滚、出错代价低的环境。写错了删掉重来Git 一分钟回滚。这个场景下Agent 只需要聪明。而且如视频所点破的这些产品本身就是 Agent 工程的产物——Codex 背后是 OpenAI 的 Agent loop、工具调用、沙箱隔离这一整套工程。所以Codex 强 → Agent 开发没必要这个推理第一环就断了你看到的越强越说明 Agent 开发的价值大只是价值被封装成了产品。思考通用 Agent 会吃掉业务 Agent的焦虑本质是把能力和责任混为一谈。通用 Agent 再聪明它对是谁的订单、谁有权限退款、这笔操作要不要留审计记录一无所知——不是它学不会而是这些信息只存在于你的系统里而且出于合规考虑永远不会开放给第三方客户端。能力可以通用责任必须本地化。这就是分水岭。答案判断一个需求该用通用工具还是业务 Agent先问一句这个操作的出错代价由谁承担、事后找谁追责答案如果是我自己改改就好写代码、写文档用通用 Agent如果是公司涉及资金和合规退款、审批必须走业务 Agent。三、业务 Agent 难在哪跑在服务端的企业员工视频用退款举了一个非常典型的例子。一个业务 Agent 处理退款不能只说我已经处理了退款——它得识别订单状态这单是已签收还是运输中有没有超过售后期调用内部接口查订单系统、支付系统、风控系统判断退款资格保护敏感数据手机号、支付信息不能进日志、不能回显给模型上下文做幂等控制同一个退款请求重试三次只能退一次钱失败补偿扣款成功但通知失败要有回滚或对账机制留下审计痕迹谁授权的、依据哪条规则、调用了哪个接口全程可回溯。这些规则和操作通用 Agent 是不可能天然知道并稳定执行的。它们必须和你的应用代码一起跑在服务端——在同一个权限体系、同一个事务边界、同一个审计框架之内才能实现真正的业务闭环。图 2退款场景的业务闭环——Agent 必须在权限、事务与审计框架内完成多步操作思考注意视频里不能只是说我已经处理了这句话——它指向的是 Agent 落地里最常见的验收陷阱把生成了正确的话术当成完成了正确的操作。Demo 阶段的 Agent 演示几乎都是前者输出一段看起来合理的文字生产环境的验收必须是后者状态真的变了、钱真的退了、日志真的有。幂等和补偿这两条尤其容易被忽略LLM 输出天然非确定重试时如果不做幂等键一笔退款可能被执行多次——这类 bug 在 Demo 里永远不会暴露上线第一周就会炸。答案给业务 Agent 的每个写操作定义验收清单① 前置状态校验订单当前是否满足条件② 幂等键同一业务请求只执行一次③ 补偿路径失败后系统处于什么状态、如何恢复④ 审计记录谁、何时、依据什么规则、调了什么接口。四条缺一不进生产。四、Agent 开发的四个真问题视频把 Agent 开发的核心价值浓缩成四个问题这四问基本覆盖了业务 Agent 的技术骨架#问题它对应的工程模块为什么通用 Agent 覆盖不了1怎么拿到正确的上下文检索、记忆、权限过滤后的数据供给私有数据不出域必须由你的服务端按权限裁剪后喂给模型2怎么跨系统完成闭环工具编排、事务、API 集成内部接口没有公网暴露编排逻辑与补偿逻辑只能本地实现3怎么证明结果是可靠的校验、评估、审计、监控看起来对不等于可追责可靠性证明是企业合规的硬要求4怎么从业务反馈里持续进化数据回流、bad case 治理、评估集迭代反馈数据在业务系统里进化闭环必须长在业务侧一个最小骨架的带护栏的业务工具调用大概长这样# 伪代码带幂等 权限 审计的业务 Agent 工具 tool(auditTrue) # ④ 审计记录调用者/时间/参数 def refund_order(order_id: str, reason: str): if not has_permission(ctx.user, refund): # 权限谁能退 raise PermissionDenied(ctx.user) state order_service.get(order_id) # ① 上下文订单当前状态 if not rule_engine.check(state, reason): # 规则售后期/风控条件 return Reject(reasonrule_engine.why()) with idempotency_key(frefund:{order_id}): # ② 幂等重试只执行一次 result payment_service.refund(state.pay_id) if result.failed: # ③ 补偿失败回滚/对账 compensation_service.enqueue(order_id) return Ok(refund_idresult.id) # 可追责退款单号可回查思考这四问其实有一个共同的隐藏前提业务 Agent 的难点从来不在模型会不会而在系统接不接受。上下文问题的瓶颈是权限体系而不是检索算法闭环问题的瓶颈是内部接口的适配与事务边界可靠性的瓶颈是评估基准与追责链路持续进化的瓶颈是数据回流管道。这也是为什么视频说实际落地复杂度远超想象——大模型能力强弱只是四问中很小的一部分变量剩下的大头是枯燥的企业系统集成。五、聪明 vs 稳定工程化手段清单视频反复强调一个对比通用 Agent 它确实很聪明但业务 Agent 它必须要稳定。从聪明到稳定之间隔着一长串工程化手段。视频快速过了一遍清单这里展开成体系业务 Agent 工程化栈视频清单 扩展工具与权限工具注册与描述、按角色收敛工具可见性、越权防护长期状态会话之外的持久记忆——订单走到哪一步、上次人工确认了什么流程编排多步操作的先后依赖、并行与汇合、超时处理人工确认高危操作退款、删除、对外发送强制人工卡点即 HITLHuman-in-the-Loop失败恢复重试策略、幂等设计、补偿事务、对账兜底评测与监控线上 trace 全链路、成功率/耗时/成本看板、bad case 自动聚类成本控制模型分级路由简单请求走小模型、缓存、token 预算合规治理敏感数据脱敏、审计留痕、操作可回溯、模型版本可锁定。思考这份清单里最反直觉的是人工确认——它看起来是 Agent 能力不足的妥协实则是业务 Agent 的必要设计。企业流程里本来就存在大量机器初审 人工终审的节点风控、财务复核Agent 不是要消灭这些节点而是把人从全量审核升级为抽样审核。把 HITL 当成架构一等公民而不是兜底补丁的团队落地速度反而更快——因为不需要等 Agent 达到 100% 可靠才敢上线。答案落地优先级建议先做审计 人工确认上线门槛不做不能进生产再做幂等 失败恢复资损防线然后是监控 评测迭代基础最后才是成本优化 模型路由效率提升。顺序反了前期的省钱会变成后期的事故。六、什么时候才值得自研 Agent视频最后给了刹车而不是油门不是所有场景都值得自研。判断标准是四个条件的交集条件含义反例不值得自研高频任务量大摊薄开发成本一年跑几次的报表生成 → 用通用工具人工点几下复杂多步骤、多系统、需要判断查一个电话号码 → 普通接口或搜索就够了私有数据 内部系统上下文和操作都在企业内纯公开信息的工作 → 通用 Agent 直接胜任严格约束 收益可量化有合规/资损要求且省下的人力可计算规则宽松、收益说不清 → 先做流程数字化别急着上 Agent四条全中自研才有真价值缺任何一条优先考虑通用工具 人工流程的组合。七、深度思考视频之外的两个补充1. 通用与业务的边界正在互相渗透买 vs 建会持续摇摆93 秒的短视频把分野讲得很干净但现实里这条线在移动Codex 们正在长出enterprise模式接入私有仓库、组织级权限、审计日志而业务 Agent 平台也在把聪明部分商品化MCP 让工具接入标准化各家模型能力趋同。会持续稀缺的不是调用模型的能力而是把模型嵌进企业权责体系的那层工程——这正是视频强调的四个问题的长期价值。买 vs 建的答案三五年内会反复摇摆但谁能把闭环做稳这个评价标准不会变。2. 400 课时 4 个落地项目还在更新本身就是最好的论据视频结尾提到博主的课程更新了 400 多个课时、做了 4 个落地项目且仍在持续更新——这恰好从侧面印证了论点如果 Agent 开发是一套可以一次学完的固定知识它早就该收敛了。持续更新意味着工具链、模型能力、最佳实践都在快速演化业务 Agent 开发更像一门持续精进的工程手艺而不是一次性的技术选型。对从业者而言这既是焦虑来源学不完也是护城河来源别人也学不完。一句话结论Codex 越强越说明 Agent 工程有价值——只不过价值从写代码转移到了把 AI 装进企业的规则、权限与审计体系里。通用 Agent 负责让个体更强业务 Agent 负责让企业敢用。任务高频、复杂、依赖私有数据、约束严格且收益可量化时自研业务 Agent 才有真价值否则先用通用工具把问题解决掉别为了架构而架构。总结要点通用产品本身就是 Agent 开发做出来的——Codex 强 → Agent 开发没必要这个推理第一环就断了。分水岭是部署形态与责任归属客户端 Agent 强在聪明服务端业务 Agent 必须稳定、按规则、有权限、可追责。业务闭环 ≠ 生成正确话术识别状态、调内部接口、保护敏感数据、幂等、补偿、审计一样都不能少。Agent 开发的四个真问题拿到正确上下文、跨系统闭环、证明结果可靠、从业务反馈持续进化。从聪明到稳定隔着工程化栈权限、状态、编排、HITL、失败恢复、评测监控、成本控制、合规治理。HITL 是一等公民不是补丁把人从全量审核升级为抽样审核Agent 不必 100% 可靠才能上线。自研判断四条件交集高频、复杂、私有数据内部系统、严格约束收益可量化——缺一先别自研。