夜雨聆风
企业AI Agent落地失败,问题出在你不想碰的那些无聊的工程基础
全文约6000字，预计阅读12分钟。Anthropic工程团队在优化AI Agent时，花在工具设计上的时间远超prompt调优。本文从这个反直觉发现出发，拆解企业级AI Agent成败的真正瓶颈：不是模型能力，不是框架选型，而是你最不想碰的那些”无聊”工程基础。
Anthropic的工程团队在优化SWE-bench（一个衡量AI解决真实GitHub Issue能力的基准测试）表现时，发现了一件事：把文件编辑工具的路径参数从相对路径改成绝对路径后，agent的错误率降至几乎为零。
没有换用更大的模型，并非更精妙的prompt，改动的就是一个路径规范。
我在构建AI Agent系统的过程中，有一个越来越强烈的体感，和这个发现指向同一个方向：决定agent准确率的不是AI有多聪明，而是围绕AI的工程基础设施有多扎实。
工具接口设计、错误处理机制、上下文管理策略，这些”无聊”的工程细节，对agent性能的影响可能比换一个更强的模型还大。
这看上去是一个悖论：agent越智能，对周围系统的工程质量要求越高。
要理解这个悖论为什么成立，需要先看看AI Agent是怎么一步步走到今天的。
“智能体”这个概念可以追溯到1977年Carl Hewitt提出的Actor Model（一种并发计算的理论框架，每个”actor”是独立的计算单元，通过消息传递交互）。
1995年，Russell和Norvig在教科书《Artificial Intelligence: A Modern Approach》中给出了agent定义：智能体，一个能通过传感器感知环境，并通过执行器对环境施加影响的实体。
从1990年代到2020年，agent基本只存在于学术论文里。BDI架构（Belief-Desire-Intention，用”信念、愿望、意图”三元组给agent一个”心理模型”）、多智能体系统研究等领域产出了大量论文，但除了军事模拟和少量机器人控制，几乎没有工业界落地方案。
原因很简单，当时没有技术能让agent真正理解自然语言和推理复杂问题。 Agent有了骨架，但一直缺一个足够强大的大脑。
2020年GPT-3出现，2022年Chain-of-Thought（思维链，让模型逐步推理而非直接跳到答案），同年ReAct框架（Reasoning + Acting，让模型交替进行推理和行动）被提出。2022年11月ChatGPT五天内获得100万用户。2023年3月AutoGPT成为GitHub历史上增长最快的项目之一。
Agent终于找到了它的大脑。然后所有人不约而同的发现：光有大脑远远不够。
在AI Agent狂热之前，企业界其实已经搞过一次”智能自动化”冲锋。那就是RPA（Robotic Process Automation，机器人流程自动化，本质是录制回放式的界面操作自动化）。
2010年代，UiPath估值飙到70亿美元，RPA成为企业软件中增长最快的品类。它能替代人类完成大量重复操作：银行对账、保险录入、HR流程。
RPA看起来很像agent，但有一个致命局限：它不会”理解”，只会”模仿”。 界面改变一个按钮，整个流程就崩了。
Deloitte的调查显示，企业部署RPA项目的失败率高达30%到50%。”RPA工作80%是处理Edge Case，当你把所有Edge Case都处理完之后，你发现你写的其实不是RPA，而是一个巨大的if-else系统。”
RPA的困境揭示了一个本质事实：真正的企业流程自动化不是一个”执行”问题，而是”理解”和”判断”问题。
实际上，你需要的不是一个手速极快的操作员，而是一个能理解上下文、做出判断、处理意外的智能助手。
LLM给了agent”理解”和”判断”的能力，但这又引出了一个新的困境。
2023年3月AutoGPT上线时，一个开发者的吐槽被广泛传播：”我让AutoGPT帮我做一件简单的事，它自己给自己发了47封邮件，创建了12个文件，最后告诉我它完成了，但实际上什么也没做成。”
自主性越高的系统，不可控性也越高。
传统软件是确定性的：给定相同输入，总产出相同输出，可以用单元测试覆盖所有分支。
Agent是非确定性的：同样的任务，每次执行的路径可能不同，结果可能有偏差。你没办法测试“所有”路径，因为路径空间近乎无限。
这意味着必须在agent和现实世界之间建造大量的防护工程：
工具接口必须精确。
Anthropic的经验：文件编辑工具从相对路径改成绝对路径，错误率几乎归零。一个path参数的规范化，效果可能超过多轮prompt优化。
错误处理必须比传统软件更健壮。
传统软件的API调用失败，你知道该重试还是该报错。Agent的一次工具调用失败，可能导致后续十步推理全部基于错误前提。需要的不只是错误码，而是足够丰富的错误上下文，让agent能理解”为什么失败”并自主修正。
权限边界必须是硬约束而非软建议。
Agent可以做什么、不可以做什么，不能靠prompt里写一句”请不要删除重要文件”来保证。必须在工具层面做硬性限制：这个工具只能读不能写，这个API只能访问指定目录，这个操作需要人类确认。
我在构建自己的agent skill系统时，有一个大致的体感：花在设计工具接口上的时间大约是写prompt的5倍。
每一个暴露给agent的工具，都要反复思考：参数是否足够明确？返回值是否包含agent做下一步决策所需的全部信息？失败时的提示是否能引导agent走向正确的修正路径？
这些工作一点都不”AI”。就是传统的API设计、接口文档编写、错误处理策略。但它对agent最终表现的影响是决定性的。
这就是悖论的完整表述：正是因为agent具备了智能判断的能力，它才有可能在更大范围内自主操作；而操作范围越大，周围系统的工程质量就必须越高。
Agent的智能释放了自动化的潜力，但兑现这个潜力的是那些最不性感的基础设施工程。
这是Harness Engineering的真正涵义：重点不是Agent，重点是外围设施。
理解了这个悖论，就不难理解2026年AI Agent框架竞争的走向。
LangChain在2022年起步时走的是”大而全”路线：集成所有LLM、所有向量数据库、所有工具。它确实帮助大量开发者快速上手，但也招来持续批评。
”LangChain把本来10行代码能做的事变成100行，然后告诉你这100行更可维护。”
批评的重点不是说功能不够，而是它在agent和开发者之间加了太多中间层。当agent行为不符合预期时，你不知道该怀疑哪一层：prompt有问题？链式调用的顺序不对？还是框架某个隐式行为在作怪？
Anthropic在2025年发表的《Building Effective Agents》有一句成为行业设计箴言的话：“大多数成功的agent实现都是各种可能性里最简单的。”
从工程角度看，每增加一层”智能”，就增加一层不确定性。不确定性越多，需要的工程防护越多。
OpenAI的Agents SDK也走了极简路线：整个框架只有四个核心概念，Agent、Tool、Handoff、Guardrail。
CrewAI专做多agent协作，API简洁度是LangChain方案的三分之一。
简单性正在胜出，因为agent系统的调试难度天然比传统软件高一个数量级。框架每多一层抽象，复杂性就增加一层。
如果你关注AI Agent领域，会注意到一个现象：编程是目前唯一被大规模验证的商业场景。
Cursor用户增长极快，Claude Code成为很多开发者的日常工具，GitHub Copilot从代码补全进化到Agent Mode能自主修改多个文件、运行测试、修复错误。巴西最大数字银行Nubank用Devin在600万行代码库上实现了12倍效率提升、20倍成本节约。
客服agent、数据分析agent、流程自动化agent都有人在做，但没有一个达到编程agent的付费规模和实际可靠性。
这不是偶然。软件代码有三个独特特性，恰好对应了agent最需要的工程条件：
输出可验证。
代码写得对不对，跑一下测试就知道。编译器和测试套件是天然的质量检测器。而客服agent的回答”好不好”、分析报告”准不准”，没有对应的自动化验证手段。
反馈即时。
代码运行失败，当场看到报错。Agent读错误信息、修改代码、再跑一次，这个循环以秒计。
问题高度结构化。
代码库本身就是agent的”世界模型”：文件结构、依赖关系、类型系统、Git历史，全部可索引。企业业务流程的”世界模型”可能散落在几十个系统和几百份文档里。
这三个特性大幅降低了agent出错的代价。
出错了，跑测试就发现，改就是了。正因如此，你可以给编程agent很大的自由度，因为有完善的”栏杆”（测试、类型检查、CI/CD）来防止它跑偏。
我的判断是：其他企业场景要达到编程agent的成熟度，首先要解决的不是agent有多智能，而是如何为agent提供与代码编译器同等质量的反馈机制。
也就是需要先为你的业务场景建造编译器和测试套件。这不是一个AI问题，是一个系统设计问题。
在框架层之上，还有一场更宏大的争夺。
2024年11月Anthropic发布了MCP（Model Context Protocol，模型上下文协议，一套让AI模型安全连接外部数据源和工具的标准接口）。核心理念是做agent世界的”USB”：三个基本原语，Resources（agent可读取的数据）、Tools（agent可执行的操作）、Prompts（预定义交互模板）。
Block、Replit等公司迅速宣布支持。但2025年4月Google推出A2A（Agent-to-Agent），专注agent之间的通信。OpenAI则押注自己的Agents SDK。
协议之争的表面是技术标准的竞争，本质是生态控制权的争夺。
谁定义了标准，谁就掌握了agent生态的入口。这让人想起互联网早期HTTP与私有协议的竞争。
MCP和A2A互相不是对手，它们解决的是不同层面的问题。
MCP解决agent与外部世界的连接（如何访问工具和数据），A2A解决agent之间的协作（如何互相通信和委托任务）。最终的生态大概率需要两者共存。
但在当下，更值得关注的不是”谁会赢”，而是这个事实：协议标准的成熟度直接决定了agent的实际价值天花板。
如果每接一个新工具都要写一套自定义适配代码，agent的边际扩展成本是线性的；如果有统一协议，边际成本趋近于零。这个差异在工具数量超过10个之后变得非常显著。
所有技术细节和竞争格局之下，一个更根本的变化正在发生。
AI Agent正在把”写代码”从生产环节变成质检环节。
传统模式下，人类负责写代码，机器负责执行。Agent模式下，AI负责写代码和执行操作，人类负责审查、测试和纠正。
Anthropic工程团队在使用Claude Code开发时发现，工程师花在写代码上的时间大幅减少，但花在设计系统，定义接口，编写测试，审查输出上的时间大大增加了。软件工程正在从”编码密集型”变成”设计和判断密集型”。
Nubank的12倍效率提升印证了这一点：不是工程师更快地写代码，而是AI处理了大量确定性工作（理解需求、写实现、修Bug），把人释放出来做不确定性工作（架构设计、需求判断、边界定义）。
这意味着三件事：
“工具设计”会成为核心工程技能。
你不只是在设计给人用的API，你在设计给AI用的API。给人用的API可以有模糊的文档，给AI用的API必须精确到防呆。参数名必须自解释，返回值必须包含所有决策所需的信息，错误消息必须指向修正方向。
“评估能力”会成为最稀缺的资源。
在编程场景有测试套件兜底。但在更广的业务场景（合同审核、客户沟通、策略推荐）中，”好”的标准本身就是模糊的。谁能定义出可操作的评估标准，谁就掌握了agent落地的关键瓶颈。 这可能是企业级AI Agent面临的最深层挑战。
“编排思维”会取代”编码思维”。
核心能力不再是”我能写出多好的代码”，而是”我能把一个模糊的业务目标拆成agent可执行的任务吗？能设计agent之间的协作流程吗？agent出错时，能快速定位是哪个环节的问题吗？”
如果你的团队正在考虑引入AI Agent，我的建议和Anthropic一样逆共识：不要从agent开始。
先问三个问题：
第一，这个场景有没有可靠的反馈机制？
如果输出质量只能靠人类主观判断，agent的可靠性很难保证。先建立可自动化的反馈机制，再引入agent。
第二，你的系统接口够不够”防呆”？
把你的API文档拿给一个实习生看，他能不能只看文档就正确调用？如果不能，agent大概率也不能。先改接口，再接agent。
第三，Workflow能不能搞定？
如果业务流程的步骤是确定的、只是每步需要AI的判断力，那用固定编排的Workflow就够了。不需要给agent自主决定下一步做什么的自由度。
只有当场景需要动态规划（事先无法确定步骤数量和顺序），且有可靠反馈机制，且系统接口已经足够健壮时，才考虑真正的Agent。
一个在demo中漂亮运行的agent到了生产环境可能因为一个参数格式问题全面崩溃。在agent的”智能”之前，先把”靠谱”做好。
企业级AI Agent的故事，表面上是一个关于AI能力不断突破的激动人心叙事。但深入工程实践层面，真正决定成败的是那些最不性感的东西：API设计、错误处理、接口文档、权限管理、评估标准。
这对有扎实工程功底的团队来说反而是好消息：你不需要成为AI专家才能做好AI Agent。你需要成为一个好的系统设计者，给AI提供一个精心设计的工作环境。
AI提供判断力，你提供可靠性。二者缺一不可。
几年后回看2026年，AI Agent带给企业的最根本变化可能不是”自动化了多少流程”，而是”重新定义了人和系统之间的关系”。
在这个新关系里，人的价值不在于执行得更快，而在于设计得更好、判断得更准。
这是一个还在非常初期的工程探索。没有标准答案，只有不断迭代的实践。但如果你是一个认真对待工程质量的人，我认为这个时代比以往任何时代都更需要你。
我是Hayden，用AI做实践的架构师，写作是我把经验变成认知的方式。欢迎后台私信添加我的个人微信，探讨企业AI落地和AI提效。