1. 为什么我劝你把“3天落地”当成一个认真的工程目标

过去一年里，我见过不少团队做Agent项目，死法惊人地一致。

有个做供应链服务的项目组，花了整整两周搭了一个“综合性智能助手”——能聊天、能写周报、能解释术语，业务方看演示的时候都说“哇”。等真让它对接WMS系统去查库存、改单子，就开始装傻：要么答非所问，要么参数缺胳膊少腿，要么直接编一个不存在的库存数量。最后项目被砍，复盘结论写着“大模型能力不足”，其实根本是需求模糊加上流程根本没跑通。

所以我特别想聊“3天落地”这个事。它不是让你把半年的项目压缩成3天去赶工，而是逼着你只做一条最窄、最高价值、能跑通业务的链路——从需求拆解到上线全流程的所有环节，全部在72小时内走完。这个时间盒是很好的工程纪律，它强制你放弃“做一个全能的Agent”这种不切实际的目标，老老实实把“一个场景里的一类任务”彻底做好。

这篇内容是给谁看的？主要是两类人：第一类，手里已经有业务系统（有API、有数据库、有业务规则），但团队还没想清楚Agent该从哪里入手；第二类，正在做Agent POC，但担心做出来又是“能说不能干”的演示品。读完之后，你会得到一张可直接用的三天推进清单，以及我在多个企业级项目里踩过、填过的坑。

先说一句结论放在前面：Agent项目的真正难点，从来不是模型不够聪明，而是工程化不够结实。3天的目标就是把这句话变成现实。

1.1 一个失败的样本：两周Demo为什么被砍

刚才提到的那个供应链项目，我再拆细一点。他们的需求是“做一个能处理订单异常的智能助手”，听起来很明确，但实际开发中所有人都在做加法。一开始只打算查订单状态，后来业务方说“能不能顺便把退换货规则也答了”，再后来产品经理说“如果用户问‘为什么我的货还没到’，咱们能不能主动查物流延迟原因”。需求面越铺越宽，到第10天时，Agent需要理解30多种意图，调用8套内部系统，其中一半系统连稳定的测试环境都没有。

最后的演示很热闹，但懂行的人一看就知道：没有一个环节经得起生产环境考验。没有超时处理，大模型卡住的时候用户只能干等；没有工具调用的校验逻辑，模型抽参数抽漏了，系统照样把空值发给下游；没有人工兜底，答错就是答错，连个“转人工”的通道都没设计。

这个案例给我最大的教训是：不是任务越复杂越有价值，而是任务越闭环越有价值。

1.2 “3天”背后的工程逻辑：用Deadline逼出优先级

坦白说，给项目设置3天时间，本身就是一种需求筛选手段。

我常用一个办法叫“三问淘汰法”，需求出现的时候连问三个问题：

• 这个需求每周出现多少次？如果每周出现不足50次，直接不进首期范围。
• 这个需求是否依赖单一业务系统？如果调用链超过两个系统，后移到二期。
• 这个需求的结果是否可以明确验收？如果“答得好不好”都没有标准，说明业务方自己也没想清楚。

用这三问过滤完之后，你会发现真正值得做的Agent场景所剩无几，但留下来的每一个都是高确定性、高频率、可验收的。我最近做一个零售行业的售后客诉Agent，就是拿这套方法砍掉了8个候选场景中的7个，只留下“查单+催发货”这一个场景，第1天晚上就把端到端流程跑通了。剩下的2天全在打磨边界条件、加工程保护，最后业务方反而觉得这个Agent比那些大而全的Demo靠谱得多。

2. 需求拆解的第一课：先定义“不做清单”

很多技术团队习惯拿到需求就画架构图，我建议反过来，先写“不做清单”。这事一旦做晚了，代价会指数级上升。

2.1 用“高频、闭环、可验收”三把尺子筛需求

关于这个问题，我可以展开说说：

• 高频：不是“偶尔能帮上忙”，而是“每天都会发生”。有真实业务数据的团队，直接翻过去一个季度的客服工单、系统操作日志、业务报表，把Top10高频操作拉出来。没有数据的，就找业务方一起做“一周排演”，把一周内可能出现的用户问题全部过一遍，能写满一整墙便利贴的，才是真需求。
• 闭环：这个任务从开始到结束，Agent能不能独立走完？比如“查快递到哪了”，用户问、Agent查、系统回，三步闭环，好做。而“帮我想想这周团购选什么套餐”，没有明确的工具、数据和成功标准，这就不是闭环任务，是开放聊天，先放一边。
• 可验收：业务层面得有判断依据。我一般会要求业务方回答一个问题：“如果这个Agent明天上线，你觉得好用还是不好用，用什么例子来判断？”能举出具体例子的场景才做。比如“客户问发货时间，Agent必须在5秒内给出准确时间，给错了算事故”——这种定义方式，开发才知道往哪个方向努力。

2.2 把业务语言翻译成一张“决策表”

需求拆解有一个非常实用的产出物，我一般叫它“意图决策表”。拿零售售后场景举例，拆完之后大概是这个样子的：

这张表的作用不是拿给模型训练，而是让开发知道Agent的“大脑中轴线”是什么。模型不在这一步自由发挥，它做的事情只是在有限意图里做一次分类和参数抽取，正确率会高很多。

2.3 边界条件清单：宁可拒绝，不能瞎猜

企业级Agent和普通聊天机器人的分水岭，就在边界条件的处理上。

个人用户的聊天机器人答错了，用户顶多骂一句然后自己重试。企业场景里，Agent答错了可能直接引发客诉、造成库存误扣，甚至触发合规问题。所以从需求拆解的第一天起，你就必须在每个意图旁边标注“不确定时怎么办”。

我自己的硬性规则是：模型置信度低于阈值（通常设在0.6左右，具体根据场景调整）时，允许的响应方式只有两种——要么直接转人工，要么明确告诉用户“我没有理解你的需求，请重新描述”，绝不强行给答案。这条规则写进需求文档，比写进代码更重要，因为业务方只有在需求阶段同意了这条兜底策略，后续验收才不会有分歧。

3. 架构落地：选型不是越重越好，编排层才是灵魂

第1天下午开始进入技术选型阶段。很多团队一上来就在纠结“用哪个大模型”，我说先别急，画清楚架构边界比选模型重要十倍。

3.1 先画一条清晰的分层线：Agent系统只有5层

我在企业项目里最常用的分层方式是这样的：

接入层负责接收各种入口的统一请求——网页对话、企业微信、客服系统接口对接，入口可以有很多个，但接入层后必须收敛成一种内部统一协议。我通常用“消息对象”作为标准结构，里面至少包含用户ID、会话ID、文本内容、附带参数（比如订单号）、时间戳。这一步不做的话，后面每个渠道都要单独适配你会疯掉。

编排层是Agent的心脏，也是整个架构里最值得投入的地方。它的职责是：意图识别、参数抽取、工具选择、结果校验、流程控制。这套逻辑一定写在应用代码里，由编程语言控制，而不是让模型自己去“想”。重复一遍这句话——不管多厉害的模型，都别让它独立决定“该调用哪个API、参数填什么”，至少初期不要。

工具层把已有的内部系统包装成模型可调用的“函数”。需要重点设计的是每个工具的参数Schema（下面第4章会细讲）。另外工具层的返回值，无论内部是什么数据结构，都要在外面加一层“展示摘要”——让模型只看到精简后的业务结果，别把各种内部状态码和原始日志喂进去。

记忆层负责上下文保持，包含两部分：短期记忆（当前任务会话中的关键信息）和长期记忆（用户偏好、历史工单摘要）。企业场景不推荐简单堆对话历史，因为Token成本和噪音都会被放大。更好的做法是设置“工作台”结构，只维护当前任务需要的参数和结果，详见第4.3节。

审计层负责记录一切，输入、输出、工具入参、出参、模型返回的原始内容、耗时、成本。这层在Demo阶段没什么用，一上线立刻变成刚需。业务有争议的时候，没有审计日志，你连自己答过什么都没法证明。

3.2 模型选型的几个务实标准

大模型选型，我用的判断维度是这样的：

这里说一个很多团队容易踩的坑：光看公开评测榜单选模型。你在公有能力排行榜看到的结果，和你业务场景的实际情况完全是两码事。正确的做法是，选型当天就构造一批你们业务特有的“脏输入”——比如订单号缺一位、用户把收货地址说了一半、用户用语音转文字所以有错别字——直接拿到各候选模型上跑一遍，看谁最抗造。记住你是去干活的，不是去评榜的。

3.3 编排框架的三个选项，我推荐哪一个

当前可选的路大致有三条。

选项A：使用较成熟的开源编排框架。这类框架帮你解决了很多通用问题，比如多轮对话、工具调用循环、记忆持久化，上手快。我大概评估过它们的定位，适合团队对Agent还比较陌生、需要在短时间内先跑通一版、同时不打算在基础设施上花太多人力的情况。代价是框架本身有学习成本和一定的抽象膨胀，很多逻辑被包在黑盒里，出了问题排查起来稍微费点工夫。

选项B：自研一个轻量编排器。这其实比很多人想象的要简单。一个意图识别函数、一个参数抽取函数、一个工具调用分发函数、一个校验与兜底函数——四个核心类，撑死了两三千行代码，却能换来极高的可控性。我们用这种方案落地过不少项目，好处是每一个环节都能打日志，每一条错误都能准确定位。代价是基础能力要自己搭，比如多轮会话管理、调用重试、状态机这类通用功能都得自己写。

选项C：纯提示词派。让模型直接看一大段提示词，要求它按流程调用工具。优点是原型快，缺点是生产环境极难控制，稍微复杂一点的工具组合就可能乱套。

我的建议很直接：如果你以后要持续维护这个Agent，别选C；如果你团队里没人深入了解过开源的编排框架，也别A，因为出了线上事故你不知道该改框架源码还是改自己的代码。首选B，用一个周末就能写完的轻量编排器，换来的是100%的可控性。

3.4 可控性是第一原则：给模型一条“窄路”走

有一点我想特别强调：企业级Agent和学术Demo之间最大的观念差异，是对“自由发挥”的态度。

Demo喜欢让模型自由发挥，显得“智能”；企业生产要的是稳定输出，智能是排在稳定之后的。所以给模型的路越窄越好：意图列表固定、工具选择固定、参数抽取有明确约束，模型只在一个极小的决策空间里做选择题和填空题。我们内部有个说法叫“Model in a Box”，意思是模型被装进一个边界明确的框里，框之外是业务代码的绝对控制区。做到这一点，你对系统的可预测性、可测试性、可审计性就都有了保障。

而企业界的人其实不太喜欢把关键业务动作全交给模型直接决策的——各个团队都有自己踩过“自由发挥”的坑，最后得出的结论几乎出奇一致。

4. 第二天：把“能聊天”的Agent改成“会办事”的任务系统

第一天结束的时候，你应该已经完成了需求拆解表、技术选型、系统分层的设计，并且搭好了工程骨架。第二天全天，目标只有一个：让Agent在一条真实业务链路上端到端跑通。

4.1 最小闭环：六个环节一个都不能少

一个能“办事”而不是“聊天”的Agent，它的每次任务处理一定是结构化的：

1. 意图识别：把用户输入分类到预定义的意图列表中。
2. 参数抽取：从文本中提取调用工具所需的字段，包括从对话历史里补全缺失字段。
3. 工具选择：根据意图和已抽到的参数，由代码逻辑决定调用哪个工具。
4. 工具调用：执行内部API请求，处理超时和重试。
5. 结果校验：把工具返回的结果和用户问题做一致性检查，判断是否满足回答条件。
6. 回复生成：基于工具返回结构，用模型生成面向用户的自然语言回复。

第2步和第5步是很多人最容易忽略的，但它们恰恰是“会办事”和“假装会办事”的关键区别。参数抽取得全，工具调用才不会失败；结果校验做得好，模型才不会把系统返回的“查无此单”硬生生编成“您的货物正在运输途中”。

4.2 工具调用的Schema才是Agent的“骨相”

如果架构有骨头，那工具调用的Schema就是骨相。参数定义得漂不漂亮，直接决定模型抽参数能不能抽得准。

拿查询订单状态举例，一个工具的函数定义大概长这样：

{ "name": "query_order_status", "description": "根据订单号查询订单的最新状态和物流信息。订单号必须完整。", "parameters": { "type": "object", "properties": { "order_no": { "type": "string", "description": "用户提供的订单号，一般为12位数字，例如202501011234。如果用户只提供部分订单号，不要尝试拼接，直接标记为缺失。" }, "user_id": { "type": "string", "description": "当前登录用户的ID，从会话上下文中获取，不需要用户重新提供" } }, "required": ["order_no", "user_id"] } }

三个经验之谈。第一，description不要写教科书式的解释，要写“给模型看的提示词”。把业务判断规则写进去，比如“订单号必须完整”“不要尝试拼接”，比你在prompt里反复强调有用得多。第二，必填参数尽量少。能不依赖用户输入的字段，就通过会话上下文注入，比如登录用户的ID；要用户输入的，也要想清楚哪些是“可后续追问补全”的。第三，返回值要做成“扁平摘要”。不要让模型去读一堆子表、嵌套字段、状态码，直接汇总成一句类似“包裹已发出，当前位于某地转运中心，预计明天送达”的文本，或者一行结构化的关键字段。模型拿到的信息越清爽，最终回复质量就越高。

4.3 记忆和上下文：给Agent一个“工作台”而不是“聊天记录”

第二天的另一个重要工程是“工作台”设计。一个对话半小时的用户，中间可能穿插各种问题，如果指望模型从几百句聊天记录里自己找“刚才那个订单号是多少”，它一定会出错。

所以我推荐每个会话维护一个结构化的任务工作台，类似这样：

每一轮对话结束，你的编排层按“先更新工作台、再做决策”的顺序处理。这种方式有两个好处：一是模型每次只需要看到工作台里的关键信息，不会迷失在历史里；二是所有参数的确认链路清晰可控，哪些是用户说的、哪些是系统给的、哪些是模型猜的，一目了然。

4.4 让流程可见：人可以在中途接管

企业级Agent还有一个标配能力是好多Demo做不到的：人在中途接管。

所谓“接管”，不是说一句“转人工”就完事，而是当前任务得能完整交接。比如Agent正在推进一个退货流程，抽到了订单号，但用户纠结要不要留退货原因，这时候用户说“算了，不退了”，Agent要能立刻终止当前意图，重置工作台，而不是执着地继续追问退货原因。

更严谨的系统里，任务状态里还有“挂起待审核”这一类。有些操作在试运行期或高风控场景下必须有人工审批，Assistant只负责把资料收集齐，然后生成一个结构化摘要，推给业务人员审核。执行权在人工手里，Agent永远只是“建议者”而不是“行动者”。

5. 上线前的工程加固：超时、重试、状态机与安全边界

第3天上午开始，进入我称之为“工程加固”的阶段。这一天的任务不是加功能，而是把最有可能会在线上炸掉的地方先补上。

5.1 大模型接口的“三超”问题：超时、超流量、超预算

所有接过大模型API的人，迟早都会在线上遇到下面的情况。模型服务商偶尔抽风，不是网络问题就是服务端限流；响应时间波动剧烈；超时的时候看起来就像系统死了。

应对方案里最基础但最有效的是三层控制：

书接上回，我先说超时。我给系统定了三个时间阈值：单次模型调用超时设为5秒，整个Agent任务端到端时长不超过15秒，超过阈值立即终止当前流程并给出兜底回复“系统有点忙，请稍后再试或转人工”。别设得太长，一个用户如果盯着屏幕等30秒，体验已经崩了，还不如快速失败让用户重试。

再说流量和预算。每次调用在编排层都要有“熔断开关”——连续5次调用失败自动熔断10分钟，期间所有请求直接走兜底文案。成本控制方面，给模型单独设置每日额度，比如一天最多消耗预算X元，超过之后自动降级为只用简单规则回复或转人工。这套逻辑在第二行代码就要加进去。

def call_llm_with_retry(prompt, max_retries=2): for attempt in range(max_retries + 1): try: # 单次超时设置为5秒，不包含排队等待时间 response = llm_client.chat( messages=prompt, timeout=5 ) return response except TimeoutError: if attempt == max_retries: return generate_fallback_reply() time.sleep(0.5 * (attempt + 1)) # 退避等待 except RateLimitError: if attempt == max_retries: return generate_fallback_reply() time.sleep(2) # 限流常见，多等一会儿 return generate_fallback_reply()

这里要特别提醒一个细节：重试只对“暂时性错误”有意义，对超过预算、鉴权失败这类“永久性错误”重试完全没有价值，白白浪费时间和资源。所以重试逻辑里一定要区分错误类型。

5.2 从“一轮对话”到“任务状态机”

到了上线前这一步，我会强制要求把Agent的任务从“无状态对话”升级为“状态机”。不要觉得这个重，其实就是把会话生命周期里的几个状态显式化。

常规任务状态至少应该是这些：

状态机的意义在于：它让Agent的行为变得可预期。比如用户在Agent查物流的路上突然问了一个新问题，状态机要能正确处理“意图切换”：当前任务挂起，新意图入栈，旧任务的参数保留在工作台里，等用户回头再说。没有状态机，这种场景会让Agent立刻精神分裂，把两个任务的信息混在一起回答。

5.3 安全与审计：Agent做出的是“建议”还是“动作”

最后一天还要认真设计一个边界问题：哪些操作Agent可以直接执行，哪些必须走审批。

我个人的原则是：只读操作可以自动执行，比如查库存、查订单、看物流；写操作必须二次确认，比如改地址、改数量、提交工单；涉及资金、删除、权限变更这类高危动作，必须走人工审批链路。这个原则说给业务方听，对方基本都会同意，因为没有人愿意让一个还不能完全信任的Agent直接动钱。

审计日志的字段，建议至少包含：会话ID、用户ID、时间戳、意图名称、模型输入摘要、模型输出全文、工具名称、工具入参、工具出参摘要、耗时、消费Token数、命中策略。落库之后别只存着不看，建议每天跑一个成本汇总和错误轮次回看。

6. 验收标准与灰度发布：怎样才算真正可以砍掉人工

到第3天下午，系统跑通、加固完成，看起来一切正常了。但能不能真正上线，还需要一套验收方法论。

6.1 四个指标，一个都不能少

我在所有Agent项目里都在用这四把尺子来衡量“能不能放量”：

任务完成率可以过滤那些“答了但没办成事”的对话；工具调用准确率单独看是因为即使任务没完成，工具调用也不能有太多错；P95时延决定用户体验；人工介入率是兜底策略执行情况的度量，太高说明Agent能力不足，太低（比如为0）反而要警惕，是不是业务规则的边界设得太保守。

验收的具体方式是准备80条带标注的测试样本，覆盖每个意图的正例、反例、边界情况（比如订单号缺失、重复追问、情绪化输入），跑完后按指标逐条算。做这一步的时候有个心态要摆正：测试样本过了不代表上线稳了，但样本都过不了，上线一定会出事。

6.2 灰度策略：影子模式 → 小流量 → 人工复核 → 全量

虽然只有3天时间，但上线环节我也不会一把梭。标准的灰度链路是四段。

影子模式：把线上真实流量复制一份给Agent，Agent的答复不触达用户，只和人工客服的真实答复做对比，目的是看它在真实数据上的表现。

小流量：比如放1%的真实用户进来，Agent直接回复，同时安排客服在旁边待命。观察刚才那四个指标，尤其关注任务完成率。

人工复核：把Agent已经完成的任务按一定比例抽出来人工复查。我第一次做合作伙伴的Agent项目时，这一步抓出了大量“看似成功实则答非所问”的样本，提前发现了上下文混乱的问题。

全量放量：指标达标后全量，同时前两周每天盯指标。

6.3 上线不是结束：错题集回灌和模型无关

项目上线以后，真正开始产生价值的是“错题集”复盘机制。我比较建议每周做一次样本评审，把当周的失败案例捞出来，分类记录：是意图分类错了、参数抽错了、工具调用逻辑出问题了，还是模型回复的时候跑偏了。

评估过很多案例后我发现一件有意思的事：六成以上的问题不在模型本身，而在工具Schema描述不清、工作台信息维护不完整、决策表的边界定义太粗。换句话说，你花再多钱换更聪明的模型，效果都不一定比花半天时间把Schema里的描述写得更清楚来得好。

所以错题集回灌更新的优先级排第一的是工具描述，其次是决策表规则，最后才是考虑换模型。这个顺序不要搞反。

对了，最后提一个我自己每次都会做的小步骤：第二天晚上，找一个没参与开发的人来当“红队”，让他对着Agent自由提问，专挑边界情况。往往他问出来的问题，比你自己准备的所有测试用例都要刁钻。这个环节最多花两个小时，但总能赶在上线前揪出一两个漏网的“灵异问题”，比上线后被用户发现要体面得多。