真正能落地的AI Agent：一个CTO推翻产品后的9个教训

Patrick Dougherty在创业过程中推翻整套产品，转而用AI Agent重构系统。这次分享不是概念宣讲，而是来自真实生产环境的教训：什么才算Agent、为什么“会想”比“知道多”更重要，以及哪些常见做法其实在拖垮Agent表现。

什么才算AI Agent？先把概念说清楚

在Patrick看来，行业里对“AI Agent”的滥用已经到了需要重新下定义的程度。很多所谓的Agent，本质只是更复杂的prompt chain。他给出的定义非常严格，只有同时满足三个条件，才配被称为AI Agent。

第一，Agent必须能够接受一个明确的目标，可以来自人，也可以来自另一个Agent，但必须是一个整体目标，而不是一连串步骤。第二，它必须能调用至少一个外部工具，并拿到真实世界的反馈。第三，也是最关键的一点，它必须能“自主判断”什么时候、如何使用这些工具，而不是预先写死流程。

Patrick在视频里强调了一句话：“If it’s just a predefined sequence of tool calls， it’s not an agent.” 这背后其实是一个非常实用的分界线：一旦工具调用顺序写死，你面对的就不再是一个会思考的系统，而是一个脆弱的自动化脚本。

这个定义之所以重要，是因为它直接决定了后续所有工程决策：你是在设计一个“能推理的系统”，还是在堆叠prompt技巧。Patrick的团队正是因为一开始选错了方向，才在两年前选择“rip apart our entire product”，彻底推翻重来。

最大的转折：不要教Agent知识，而是给它思考的能力

这是整场分享中最反直觉、也最有价值的一点。Patrick坦承，他们一开始也走了业界最流行的路线：把尽可能多的知识塞进prompt里，用RAG（检索增强生成）提前喂给模型背景信息。

但在真实产品中，这条路很快撞墙。他们做的是一个让AI Agent查询企业数据仓库的产品，典型任务是：根据自然语言问题，自动生成SQL查询。问题出现在“好心办坏事”——当他们把所有表结构、所有字段一次性塞进上下文窗口，Agent反而更容易选错表、写出无法执行的SQL。

Patrick用一个非常具体的场景说明问题：当上下文里token数量过多时，模型会被信息淹没，推理能力下降。于是他们改变策略，不再把知识直接写进prompt，而是设计更小、更离散的工具调用，比如“搜索相关表”“获取表结构”“分析某一列的分布”。

Agent被迫一步步用这些工具去探索数据，而不是一次性‘背答案’。Patrick总结他们的转变时说：“We focused on enabling the agent to think， not on what the model already knows.” 这也是他们产品性能真正开始提升的转折点。

GPT-4o vs 推理模型：一个关于“该不该写SQL”的残酷案例

为了说明“推理能力”在生产环境中的差异，Patrick现场对比了GPT-4o和o1的表现。实验非常简单：给模型一份标准的Salesforce表结构，然后问一个看似合理的问题——“写一个查询，看看上个月有多少客户流失了”。

在GPT-4o上，结果几乎是灾难性的。即使表结构里根本没有定义“流失（churn）”所需的状态字段，GPT-4o依然会“非常积极地”编造一个SQL查询。Patrick直言，这种行为对分析师是致命的，因为“它看起来很专业，但答案是错的”。

而在同样的prompt下，o1的反应完全不同。它先分析问题所需的数据条件，然后明确指出：在当前schema下，根本无法计算客户是否流失。这个“不写SQL”的决定，反而是企业真正需要的答案。

Patrick用这组对比说明一个关键观点：不是所有模型都适合当Agent的大脑。如果你的系统奖励的是‘一定要给答案’，那模型就会不断编造。真正可用的Agent，必须被允许说‘我不知道’。

被低估的工程细节：ACI、模型选择与微调的误区

如果说“推理优先”是方法论，那么ACI（Agent Computer Interface）就是决定生死的工程细节。ACI指的是工具调用的具体接口设计，包括参数结构和返回格式。Patrick分享了一个非常现实的教训：哪怕只是把工具返回格式从Markdown改成JSON，都可能立刻解决GPT-4o的“上下文失明”问题。

更有意思的是，不同模型对格式的偏好完全不同。同样的工具接口，Claude在XML格式下表现更好。这意味着，Agent性能问题，很多时候并不是模型不行，而是你“说话的方式”不对。

在模型选择上，Patrick把模型比作Agent的“大脑”：负责决定下一步做什么的模型，必须足够聪明，哪怕其他子任务可以用更便宜的模型完成。他提到，Claude 3.5在速度、成本和决策质量之间取得了一个很好的平衡。

至于微调（fine-tuning），他们的结论非常直接：浪费时间。微调往往会固化模型行为，削弱推理能力。与其微调模型，不如反复打磨ACI。这一点，对很多还在大量投入微调的团队来说，是一次非常现实的提醒。

多Agent系统与真正的护城河在哪里

在多Agent设计上，Patrick并不推崇复杂的群体协作。他们的经验是：5到8个Agent最理想，再多就会引发无限循环和责任模糊。关键在于引入一个“Manager Agent”，对最终结果负责，而不是规定每一步该怎么做。

激励机制同样重要。Patrick建议奖励Manager Agent“是否达成目标”，而不是是否严格执行流程。这和前面强调的“允许思考”一脉相承。

在分享的最后，他给出了一个颇为冷静的结论：“Your agent is not your moat.” Prompt、Agent逻辑都不是核心壁垒。真正消耗时间、也真正构成护城河的，是周边系统：权限、安全、审计、以及与真实业务流程的深度集成。

这也是为什么很多Demo级Agent看起来惊艳，却很难进入生产环境。Agent本身只是开始，真正困难的，是让它在现实世界里安全、可靠地工作。

总结

Patrick Dougherty的分享之所以珍贵，是因为它来自一次“推翻重来”的真实代价。核心启发很清晰：别把Agent当成更聪明的搜索引擎，而要把它当成一个需要被允许思考、被正确约束的系统。少塞知识，多给工具；少微调模型，多打磨接口；Demo可以追求炫技，但生产环境必须尊重现实复杂度。这些教训，几乎无法只靠论文或博客获得。

关键词： AI Agent， 推理模型， GPT-4o， Claude， 检索增强生成

事实核查备注： 人物：Patrick Dougherty（Rosco联合创始人兼CTO）；视频标题《How to Build AI Agents that Actually Work》；发布时间2025-02-22；产品与模型：GPT-4o、o1、Claude 3.5；关键概念：AI Agent三要素、ACI（Agent Computer Interface）、RAG、上下文窗口、Token、微调对推理的影响；案例：Salesforce表结构下计算churn的SQL示例。