我接手过好几个和AI代理相关的项目，最初总觉得最难的是模型选型或者提示词编写，真正干下来才发现，最难的是让一个由模型驱动的代理系统在真实业务里稳定跑完一件小事。AI原生应用这个概念这两年被反复提起，但团队里真正动手做过的人都知道，把AI嵌进传统软件是一回事，把整个业务流程交给AI代理去自主决策和执行，是另一回事。这篇文章我想用两个亲手跟过的项目，拆一拆AI代理在AI原生应用里的实战细节——一个是售后工单自动处理，一个是竞品情报研究。两个方向完全不同，但踩过的坑高度相似，方法论也能互相迁移。如果你正准备做类似的项目，或者已经在AI原生应用的路上被代理的不可控性折磨，这篇内容应该能帮你少走几步弯路。
1. 先别急着写代码：想清楚什么才算真正的AI原生应用
我在多个项目里见过所谓"AI原生应用"的真实形态，大部分其实只是两件事：给传统软件加一个聊天入口，或者把某个环节换成模型调用。这两种做法我都用过，也为此付出过代价。
1.1 两种"伪AI原生"的常见形态
第一种是"AI增强"。底层还是传统CRUD系统，业务流程全部写死，模型只在一个小环节里充当"高级文本框"。比如原来的搜索改成向量检索，工单分类改成由模型输出类别。这种改法当然有收益，但它没有改变业务流的本质——决策节点依然是写死的，模型只是被用来做了一次格式化输出。
第二种是"AI包装"。把一次对话当成全部，没有工具调用、没有状态管理、没有后续动作。用户跟一个聊天机器人聊了二十分钟，最后发现它除了聊天什么都干不了，所有后续流程还得靠人工在后台完成。这类项目上线时的演示效果很好，真跑起来价值很低，因为它只是"算法输出"，不是"业务闭环"。
我认为，判断一个应用是不是真正的AI原生，关键看一个标志：业务流中的决策节点有没有被模型动态产生，而不是预先编码。传统应用是"if-else"决定分支，AI原生应用是"模型根据当前上下文决定下一步做什么"。而AI代理，就是这个决策过程的最小执行单元。
1.2 AI代理在AI原生应用里的真实角色
一个完整的AI代理，至少要具备四个能力：感知、规划、行动、反思。感知是读取用户输入和工具返回的结果；规划是把一个模糊的大目标拆解成可执行的子任务；行动是真正调用工具、操作API、访问数据；反思是回头检查自己的结果对不对，错了就纠正，缺信息就补充。
这和普通"模型调用"的区别在于：模型调用是单次问答，输入进来、答案出去，完了。代理是多轮循环，它可以调用工具、观察结果、调整策略、继续执行，并且对环境产生真实影响。换句话说，模型只是"会说话"，代理是"会办事"。
但我从来不建议一上来就全家桶式地用代理。我给自己定了一条判断标准：如果任务可以穷举为有限规则，就千万别用代理，规则引擎又便宜又稳定；只有任务输入的随机性强、判断边界模糊、或者需要多步工具操作才能完成的时候，才值得上代理。用代理不是因为赶时髦，而是因为它适合开放问题。下面这两个案例，恰好一个是"执行路径相对明确但输入碎片化"，另一个是"输出开放但过程需要强约束"，可以作为两种典型场景来研究。
2. 案例一：售后工单处理代理——把"能说会道"变成"能办事"
第一个案例来自我参与的一个电商售后项目。业务方每天收到几千条售后工单，客服人力严重不足。工单类型集中在退货、换货、退款咨询、物流异常四类，看起来并不复杂，但处理起来很麻烦。
2.1 业务背景与为什么不用固定流程
最初业务方的想法很直接：用规则引擎加关键词匹配来做自动回复。比如输入"退货"就触发退货流程模板，"换货"就触发换货话术。听起来没问题，真上线就发现，用户的表述千奇百怪："我的手机用了三天想退货"、"帮我退掉，快"、"这个商品和描述不符，我要退"——规则引擎的关键词完全不一样，而且一句"我要退"在不同上下文里可能是退货、是退款、是对物流不满想发泄。规则越写越多，误判率反而越来越高，最后客服团队见到自动回复系统就头疼。
后来我们做了一个决定：不搞规则系统，改用AI代理。但目标定的很克制——不是替代所有客服，而是先把有明确处置路径的工单自动处置掉，处置不了的给客服生成一份摘要建议，让客服直接基于摘要做判断。这个度量标准特别重要，后面我会反复强调：AI原生应用的第一版，目标越窄越好。
2.2 代理的工具链和提示词设计
我们给代理设计了五类工具，原则是细粒度API全部合并成粗粒度工具，减少模型的选择空间：
- 查询订单：传订单号或手机号，返回订单状态、购买时间、订单金额、商品信息
- 查询售后政策：传商品类目、购买时间、售后类型，返回是否支持退换、政策条款
- 计算退款金额：传订单号，返回实付金额、运费、可退金额
- 创建退货单：传订单号、退货原因、退款金额，返回退货单号
- 转人工：传工单号、代理摘要，生成人工任务
工具数量严格控制在五个。这不是拍脑袋定的，我们实测过：工具列表超过十个之后，模型在"该调用哪个工具"这一步的错误率会明显上升，尤其是两个工具名相似的时候，选错概率高得离谱。工具命名也有讲究，我后来都习惯用"动词+对象"的格式，比如"查询订单"而不是"订单查询"，模型对动作性描述的理解更好。
下面这段是当时精简过的提示词模板，可以直接作为参考：
你是一个售后工单处理代理。你的目标是在政策允许范围内， 尽可能独立完成用户的售后请求。 你必须遵守以下规则： 1. 用户的任何诉求，都必须先通过工具获取事实数据（订单、 政策、金额），严禁未经核实就给出结论。 2. 你唯一能输出给用户的文本，必须包含完整理由，理由必须 指向某个具体数据字段或政策条款。 3. 如果工具返回的结果不足以回答用户问题，你必须调用 追问工具（由系统映射为用户补充信息入口），不得自行假设。 4. 当你无法决策时，调用转人工工具，并输出一段不超过50字 的摘要。 5. 你的最终输出必须是如下JSON格式： { "question_answered": true/false, "tool_calls": ["工具名", ...], "conclusion": "给用户的最终文本", "reason": "结论依据", "need_human": false }这段提示词里，第2条和第3条是反幻觉的关键。很多时候模型不是不会做，而是太想"表现自己"了，你一问它不知道的东西，它就顺着语气编。把输出约束成JSON且必须带原因字段之后，编造情况的概率显著下降，因为模型至少得为自己的结论找一个可指向的字段。第四个规则很重要：代理能承认自己干不了。我们宁可让它早点转人工，也不要让它硬答。
2.3 一条真实工单的完整执行轨迹
我拿一条最典型的工单拆一下完整的执行过程。用户提交的原文是："我上周买的那双鞋，尺码偏小，想换大一码。"
代理的第一轮动作是意图识别和需求分析。它判断这是"换货"需求，需要先确认订单信息，但用户没有提供订单号或手机号。按照规则3，它不能瞎猜，于是触发追问工具，回复用户"请提供下单时填写的手机号或订单号"。
用户补齐手机号之后，代理进入第二轮。它调用查询订单工具，拿到了订单数据：商品是一双运动鞋，购买时间是8天前。接着调用售后政策查询，传参商品类目是鞋服、购买时间8天、售后类型是换货，工具返回了一个关键结果：该商品的换货期是7天内，当前已经超期，但退货期是15天内，仍然在有效期内。
第三轮，代理没有直接说"不能换"，而是把事实组合成业务逻辑：不能换货，但可以退货重拍。它调用计算退款金额工具，确认可退金额包含商品实付金额和免运费政策，然后生成了用户话术：订单已超过换货期限，但仍在退货期限内，可以申请退货并重新下单，目前尺码大一码的库存充足，是否要协助发起退货申请？整个过程中代理没有执行创建退货单，因为要等用户确认。
这条轨迹是个很典型的"两轮交互解决问题"案例。代理没有输出任何凭空内容，每一句话都指向订单字段、政策条款或金额计算。从项目数据看，这类有明确处理路径的工单，代理的独立处置率做到了接近四成，剩余转人工的工单里，客服也因为在摘要里提前拿到了订单事实和处理建议，平均处理时长下降了一截。
3. 案例二：竞品情报研究代理——把"写报告"变成标准交付物
第二个案例是给一个市场团队做的竞品情报研究代理。需求非常场景化：每周出一份竞品动态周报，要覆盖产品新功能、定价和套餐变化、用户评价趋势。最开始这个报告是研究员手工做的，一周要花将近两天时间。我们的目标不是让AI代理直接替代研究员，而是把数据采集、初筛、结构化整理这些脏活交给代理，研究员只做最后的方向判断和润色。
3.1 研究类任务的难点不在生成，而在克制
这类任务和客服工单完全不同。客服工单的"正确"是明确的——退还是不退、退多少钱，有政策依据。研究报告没有唯一正确答案，模型很容易找到一堆材料然后写出一篇看起来头头是道的内容——但内容里的每一个判断都可能有问题，可能是信息过时，可能是把不同来源的内容混在一起，也可能直接把训练时的记忆当成采集到的数据输出来。这就是研究类任务最危险的地方：生成文本对模型来说太容易了，难的是让它做个诚实的调研者，而不是戏剧编剧。
所以我们把整个项目定性为"克制型生成"。代理的每一句结论都必须能追溯到某个具体的检索来源，没有来源就不能出现在最终报告里。宁可报告里留白，也绝不允许模型发挥。
3.2 四阶段流水线的设计逻辑
我们没有让代理自由规划任务，而是用它做了一个带强约束的四阶段流水线：规划、采集、分析、成稿。四个阶段共享同一个上下文，但每个阶段有独立的提示词和独立的状态记录。
规划阶段，代理把"本周竞品动态"这个大目标拆解成一组检索任务，比如"查某产品是否有版本更新"、"查某产品定价页是否变化"、"查某平台近一周用户关于某功能的新讨论"。每个检索任务都带优先级和预期产出。
采集阶段，代理针对每个检索任务选择合适的检索渠道，抓取后做去重和正文提取。这里有个关键细节：采集到的原始页面不会直接进入最终报告，每个页面都会先被压缩成一个结构化记录，包含标题、URL、抓取时间、主要内容摘要。压缩这一步是控制成本和避免上下文过载的核心，稍后细说。
分析阶段是对结构化记录做交叉验证。比如一个检索任务命中了三条不同来源的信息，代理需要判断它们是否一致。如果不一致，它应该重新回到采集阶段去补充检索，而不是自己拍板。这个回流机制是整个流水线能落地的基础，我们在工程上实现为：允许代理调用"重新检索"工具，但必须说明新检索的目标是什么。
成稿阶段，代理按照固定模板输出报告：每条动态分列事件描述、影响判断、来源链接、可信度标记。所有无法核实的信息，一律标记为"未核实"，这部分内容不参与最终周报，而是单独列在附录里供研究员参考。
3.3 防止报告"编得有模有样"的落地手段
防止幻觉不能靠提示词里的祈使句，要靠三条具体的工程约束。
第一条是证据最小集约束。我们在成稿阶段的提示词里写死了一条规则：每个结论至少对应一条证据记录，证据必须来自采集阶段的结构化记录，报告里必须输出证据的URL。如果一条结论找不到证据，代理只能输出"未找到可核实信息"，不允许用常识补齐。
第二条是独立的事实核查步骤。报告生成之后，不直接交付，而是触发一个只做核查的代理或脚本，逐条把报告里的结论和原始证据做匹配。虽然这一步也会消耗token，但绝对物有所值，它能拦截掉相当一部分"看起来合理但证据对不上"的问题。
第三条是评测集设计。我们建立了一个小型评测集，大约50条已标注的真实调研问题，每条都有人工确认的标准检查项：事实是否准确、引用是否匹配、是否遗漏关键信息。每周迭代prompt或工具时候，先跑一遍评测集，对比分数波动。这个评测集成了项目往后每一步迭代的安全网。
关于这个案例还有一句扎心的实话：研究报告的价值在信息密度而不在文笔。看过AI生成周报的人都会有同感，它写出来往往很"顺滑"，读完却抓不住重点，因为模型不自觉地填充了大量每个人都懂的正确废话。所以我们刻意要求报告每个事件描述不超过三句话，能一句话说完的绝不两句，硬生生把生成内容的"废话率"压下去了。
4. 两个案例背后躲不开的三个工程问题
案例具体，但方法论是通用的。在两个项目先后跑起来之后，我发现它们背后其实躲不开三个共同的工程问题：任务编排、记忆与上下文管理、工具调用的可靠性。这三个问题解决不到位，AI代理项目基本只能停留在Demo阶段。
4.1 任务编排：全自动、半自动和人在回路的平衡
任务编排的第一件事，是决定系统里有没有人在回路。售后工单场景，我们做的是全自动——代理自己判断、自己调用工具、自己生成结论，只有在无法决策时才转人工。这个场景适合全自动，因为决策边界清楚，失败代价低。最坏情况下，代理搞错了，用户提起投诉，还有人工兜底。
竞品情报场景，我们做的是半自动。代理完成采集、初筛、初稿，最终报告必须由研究员确认后才发送。为什么不敢全自动？因为研究的判断标准模糊，代理可能自认为完成了一件分析工作，但研究员的视角里那完全是跑偏的。与其事后补救，不如在关键节点卡一道人工确认。我们把这道确认操作做得很轻——研究员可以一键接受，也可以改一句话返回重跑，不用重新看原始数据。
第二件事是动态规划和固定流水线的取舍。客服工单场景，工单类型相对固定，但每类工单内部的处理路径差异很大，所以代理按固定意图识别后动态规划子任务。情报研究场景，整体流程高度一致，所以采用固定四阶段流水线。我的体会是：流水线是硬约束，动态规划是软能力。如果一个任务能拆成固定阶段，就别让代理在阶段选择上消耗决策成本——自由发挥的转角，往往是出错率最高的地方。
此外，一定要给代理设置最大步数限制。我们早期做过一次很惨烈的测试，一个代理处理一条复杂工单，在"查询售后政策"和"计算退款金额"两个工具之间来回跳了十几轮，最后发现是政策工具返回的结果表述不清，导致代理反复解读。那次之后我们给所有代理加了两道闸：单任务最多执行十步，超过就自动转人工；每个工具调用次数单独配额，同一工具连续失败三次就强制停止。成本可控，容错边界明确。
4.2 记忆与上下文管理：长任务如何不把预算烧光
AI代理最大的隐性成本是上下文膨胀。每多一轮工具调用，旧的工具返回和中间推理就要继续占token位置。调研类任务的检索结果动辄几万字，全塞进上下文，第一文本质量会下降，模型会被大量冗余信息干扰找不到关键内容；第二调用成本呈线性上升，团队容易在月底对账单崩溃。
我们的通用解法是分段摘要。每个阶段结束，把当前阶段的原始上下文压缩成结构化摘要，下一步只读摘要，不读原始内容。举个例子，采集阶段抓了十五个页面，原始正文加起来有两万字，但真正进入分析阶段的只有十五段每条不超过两百字的摘要。每个摘要还带上时间和来源URL，分析阶段需要查原始内容时，再去调用检索工具取原文。
对存在长期记忆需求的任务，比如售后代理要参考历史同类工单的处理意见，不要把历史对话全部堆进去，而是用向量检索只取最相关的几条。我们做过一个对比实验：在上下文里堆一百条历史工单，准确率反而低于只取最相关的十条。原因很简单，无关历史只是噪音，而且它会稀释当前任务的事实密度。
还有一个经验：数据压缩要有策略，不能眉毛胡子一把抓。售后工单场景，订单详情和用户地址这类字段对后续决策基本没有影响，可以在摘要阶段主动丢弃。政策条款的结构化字段必须保留原文，因为它是决策依据。舍弃哪些字段、保留哪些字段，这个取舍比"怎么压缩"更重要，我建议让业务人员参与定义保留字段，而不是让程序员自己拍脑袋。
4.3 工具调用的可靠性：异常恢复与权限边界
代理能不能在生产环境稳定跑，很大程度取决于工具调用的可靠性，而不是模型的聪明程度。我最常遇到的问题有三个。
第一个是参数幻觉。模型在调用工具时可能填错参数，比如订单号和手机号搞混、金额字段把实付金额当成了可退金额。纯靠提示词纠正作用有限，我们后来的做法是做"参数约束生成"：不让模型自由填参数，而是把参数候选值显式给出来，让模型从候选里选。比如订单查询工具，先让代理把"可能的下单手机号"列出来，再由系统做一次校验匹配。这个改动让参数错误率大幅下降。
第二个是失败重试的分类处理。工具调用失败要分清楚是参数错误还是服务端错误。参数错误不能重试，应该回到"追问用户"环节补齐信息。服务端错误可以等几秒重试一次。这个逻辑看起来简单，但如果没有在代理里显式实现，模型会自行决定反复调用同一个工具，造成资源浪费和死循环。
第三个是权限边界。代理能动的每一件事，必须在工具层做最小化权限控制。售后代理能查退款金额，但不能改订单价格；能创建退货单，但不能绕过风控审批。这个边界不能写在提示词里让模型"自觉遵守"，而要落到API的鉴权层。模型从本质上说是一个概率系统，哪天它抽风调用了不该调的接口，只有权限控制能兜住。每一次工具调用，都应该记录操作者和操作对象，保证后续能审计。
5. 复盘：我踩过的坑和我现在的做法
项目做完了，最值钱的部分其实是复盘。这一节内容比较私人，但我觉得比任何方法论都更有用，都是真金白银换回来的教训。
5.1 翻车现场清单
第一个坑是让代理"全自动地追求完美"。早期版本里代理遇到模糊指令时会反复追问，用户问三个问题它反问五个问题，最后用户直接流失。后来我们限制了追问轮数，并在第一轮就把"需要哪些信息才能继续"全部列出来，用一次提问代替多轮来回。
第二个坑是评测集变成训练集。我们一开始用30条测试数据反复调prompt，调了一周之后所有测试都满分，上线后第一周就被用户的开放式问题击穿。后来评测集分成两部分，一部分是固定的回归集，另一部分是每周从线上抽样新增的留出集，这个做法直接杜绝了过拟合式调参。
第三个坑是日志不完整。代理跑错的时候，如果日志里只有"调用失败"而没有完整的输入参数和返回值，排查基本等于大海捞针。后来我们定了一条硬规矩：每一个工具调用，前后都要有完整记录，包括参数、返回结果、token消耗、耗时。这项工作很繁琐，但在出问题时救命。
第四个坑是试图做一个万能代理。让一个代理又处理售后又做用户画像还兼顾营销推荐，结果是什么都做不好。现在我的原则是宁可让多个专精代理并行，也不要拼一个"全才"。专精代理的提示词和工具都不复杂，出错也更容易定位。
5.2 我给自己定的三条铁律
第一条，先把一条主链路跑到95分，再去扩展横向场景。我的第一个售后代理只处理退货一种工单类型，跑稳定之后才逐步放开换货、退款咨询、物流异常。窄场景更容易做好评测、积累经验，经验足够之后扩场景其实是把成熟模板复制一遍。
第二条，所有对外输出都可追溯。每一句给用户的话，背后要么有订单数据、要么有政策条款、要么有工具返回，绝不能是模型自由发挥。这一条看起来是产品原则，实际上对技术架构有直接影响——它决定了上下文里哪些数据必须保留，哪些可以由模型省略。
第三条，评测先于迭代。没有评测体系的AI代理项目，后面每改一版prompt都是一次开盲盒。现在我的标准流程是：任何新改动，先在固定评测集上跑分数，分数过了再灰度放量，放量期间用日志里的真实案例补充评测集。这套流程不热闹，但踏实。
我后来把所有项目都改了同一个规矩：任何AI代理要上线，必须能回答"它最后一步到底做了什么、为什么这么做"。想清楚这两句话，技术选型、工具设计、评测标准就都顺了。如果你正在做一个AI原生应用，我的建议是别贪大，先找一个边界清晰、频次高、失败代价低的场景，把代理完整地跑起来，工具链慢慢加厚。等一条链路跑得又稳又省，你自然会知道下一步该往哪个方向扩。
