从澳龙案例看AI Agent如何落地供应链自动化

1. 从一条“游出澳龙”的消息说起：这个项目到底在做什么

第一次看到“杭港科技大厦‘游出’澳龙！智谱 AutoClaw 上线”这个标题，我脑子里冒出来的第一个念头是：这又是什么营销噱头？澳龙和科技大厦、和 AutoClaw 能扯上什么关系？但仔细拆解之后发现，这其实是一个非常典型的“AI Agent 落地真实业务场景”的案例，而且切入点选得相当刁钻——用一只龙虾，把一整套自动化智能体的能力串了起来。

先把话说清楚：这里的“澳龙”指的是澳洲淡水龙虾，一种在水产养殖和餐饮供应链里都算高价值品类的生物。“杭港科技大厦”是一个产业园区/办公场景的代称，而“智谱 AutoClaw”则是这套系统的核心——一个基于大模型能力的自动化智能体（Agent）工具链。标题里那个“游出”用得很有意思，它不是“发布”“上线”这种常规动词，而是用了一个带有生命感和流动感的词，暗示这只龙虾是从一个物理空间（大厦）里“活生生”地被一套智能系统给“运作”出来的。

那这个项目到底解决了什么问题？我个人的理解是：它把 AI Agent 从“只会聊天、写文案”的层面，推进到了“能操作真实业务系统、能驱动物理世界流程”的层面。具体来说，AutoClaw 这套东西大概率是围绕水产供应链场景做的自动化闭环——从订单识别、库存查询、物流调度，到最终的履约交付，中间可能还涉及多系统之间的数据打通和任务编排。它适合谁来参考？我觉得三类人最应该看：一是做 AI Agent 落地的产品和技术同学，二是传统行业里想用 AI 提效的业务负责人，三是供应链、餐饮、生鲜电商领域的技术决策者。

为什么这个案例值得单独拿出来讲？因为市面上大多数 Agent 项目都停留在 Demo 阶段，能跑通一个“查天气+发邮件”的流程就已经拿出来吹了。但 AutoClaw 这个名字本身就带有强烈的“抓取”“钳制”“执行”的意味，它要解决的是真实业务里那些脏活累活——比如多个系统之间字段不统一、审批流卡在某个节点、库存数据延迟导致超卖等等。这些东西不是靠一个 Prompt 就能搞定的，需要一套完整的工程化方案。

2. 核心思路拆解：为什么是“Agent+供应链”这个组合

2.1 从“对话式 AI”到“执行式 AI”的跨越

过去两年，大家见惯了各种大模型产品，但绝大多数都是“你问它答”的模式。你问它“今天龙虾库存多少”，它只能根据你给它的上下文瞎编一个数字，因为它根本没有连接真实的库存系统。AutoClaw 这类项目的核心突破在于：它把大模型的推理能力和真实系统的 API 调用能力做了深度绑定。

我打个比方：传统的聊天机器人就像一个坐在办公室里只会接电话的文员，你问他什么他只能凭记忆回答，记错了也没办法。而 AutoClaw 更像是一个手里拿着钥匙、能直接去仓库开门查货的调度员。你问他“还有多少澳龙”，他会真的去查库存系统，然后告诉你准确数字，甚至还能顺手把低于安全库存的品类自动生成补货单。

这个跨越的技术难点在哪里？第一是意图识别要足够准，用户说“帮我看看澳龙够不够卖”和“澳龙库存还剩多少”其实是同一个意思，但表述完全不同，模型必须能归一化处理。第二是工具调用要足够稳，大模型有时候会“幻觉”出一个不存在的 API 或者传错参数，这就需要有一套严格的工具注册和参数校验机制。第三是执行结果要可追溯，每一步操作都要有日志，出了问题能回滚。

2.2 为什么选水产供应链作为切入点

很多人可能会问：AI Agent 能做的事情那么多，为什么偏偏选龙虾？我分析下来有几个原因。

第一，水产供应链的痛点足够痛。这个行业的特点是：品类多、价格波动大、时效性极强、信息不对称严重。一只澳龙从产地到餐桌，中间要经过捕捞、暂养、分级、打包、冷链运输、报关（如果是进口）、批发、零售等多个环节，每个环节的信息系统可能都不一样。传统做法是靠人工打电话、发微信、填 Excel 来协调，效率低且容易出错。

第二，数据相对结构化。虽然环节多，但每个环节的核心数据无非就是：品种、规格、数量、价格、时间、地点。这些字段非常适合用 Agent 来做自动化处理。相比之下，如果你让 Agent 去处理一个创意设计流程，那就很难定义什么叫“成功”。

第三，闭环短、反馈快。一笔龙虾订单从生成到履约，可能就几个小时。这意味着 Agent 的决策效果可以很快被验证，错了马上能调整。如果是房地产交易那种长周期场景，Agent 做错一个决策可能几个月后才发现，迭代成本太高。

2.3 AutoClaw 的架构猜想与工程取舍

虽然我没有拿到 AutoClaw 的完整技术文档，但基于这类项目的常见实践，我可以合理推测它的架构大概分四层。

最底层是模型层，大概率用的是智谱自己的 GLM 系列模型，可能针对工具调用场景做了微调。往上一层是工具层，把库存查询、订单创建、物流下单、消息通知等能力封装成标准化的 API，每个 API 都有清晰的入参出参定义。再往上是编排层，负责把用户的自然语言指令拆解成多个步骤，决定先调哪个工具、后调哪个工具、中间要不要人工确认。最上面是交互层，可能是企业微信/钉钉机器人，也可能是一个独立的 Web 界面。

这里面的工程取舍很有意思。比如要不要让 Agent 完全自主执行？我的经验是：涉及资金、库存扣减、合同签署这类高风险操作，一定要加人工确认节点。AutoClaw 如果做得成熟，应该会有“建议模式”和“自动模式”两种。建议模式下，Agent 只生成操作建议，由人工点击确认后才执行；自动模式下，Agent 可以直接调 API，但会有额度限制和频率限制。

另一个取舍是用单 Agent 还是多 Agent。单 Agent 的好处是链路短、延迟低，但能力上限也低。多 Agent 可以分工协作，比如一个负责理解需求，一个负责查数据，一个负责执行，但协调成本高，容易出现“三个和尚没水喝”的情况。从“AutoClaw”这个名字来看，我倾向于认为它用的是“主 Agent + 子工具”的模式，而不是多个 Agent 互相聊天。

3. 核心细节解析：Agent 落地供应链的五个关键环节

3.1 意图理解：怎么让模型听懂“行话”

供应链场景里充满了行话和简写。比如“澳龙”可能指澳洲淡水龙虾，也可能指澳洲岩龙虾，不同品种价格差好几倍。再比如“走一批”可能指发货，也可能指采购。如果模型没有经过领域适配，很容易理解错。

我实测下来比较有效的做法是：建一个领域词典，在 Prompt 里做动态注入。具体来说，就是维护一个 JSON 文件，里面列出所有品类名称、规格缩写、常用动词的同义词。每次用户输入进来，先用一个轻量级的检索模块把相关词条捞出来，拼接到 System Prompt 里。这样既不用微调模型，又能保证理解准确率。

{ "澳龙": ["澳洲淡水龙虾", "淡水澳龙", "红螯螯虾"], "走一批": ["发货", "出库", "安排物流"], "够不够卖": ["库存是否充足", "可用库存查询"] }

注意：这个词典需要持续维护，最好让业务人员也能编辑。我见过太多项目因为词典更新不及时，导致新品类上线后 Agent 完全不认识。

3.2 工具调用：API 设计的三个原则

Agent 要执行操作，必须依赖后端 API。但给 Agent 用的 API 和给人用的 API 设计思路完全不一样。

原则一：一个工具只做一件事。不要设计一个“万能接口”让模型自己传 action 参数，那样模型很容易传错。应该把“查库存”“创建订单”“取消订单”拆成三个独立的工具，每个工具的入参尽量少。

原则二：参数要有强类型和枚举约束。比如“规格”这个参数，不要用自由文本，而是用枚举值：["1斤以下", "1-1.5斤", "1.5-2斤", "2斤以上"]。这样模型在生成参数时，只能从这几个值里选，大大降低出错概率。

原则三：返回值要包含足够的上下文。不要只返回一个数字，要返回结构化的 JSON，包含单位、时间戳、数据来源等信息。这样模型在后续推理时才能做出正确判断。

# 工具定义示例 tools = [ { "name": "query_inventory", "description": "查询指定品种的当前可用库存", "parameters": { "type": "object", "properties": { "species": {"type": "string", "enum": ["澳龙", "波龙", "小青龙"]}, "spec": {"type": "string", "enum": ["1斤以下", "1-1.5斤", "1.5-2斤", "2斤以上"]} }, "required": ["species"] } } ]

3.3 多步编排：怎么处理“查库存→比价→下单”这种链路

真实业务里，用户的一句话往往对应多个步骤。比如“帮我看看澳龙库存，如果不够就从供应商那边补一批”，这里就涉及：查库存→判断是否低于阈值→查供应商报价→选择最优供应商→创建采购单。

AutoClaw 这类系统通常会用ReAct 模式（Reasoning + Acting）来做编排。简单说就是让模型先“想一步”，再“做一步”，循环往复直到任务完成。但纯 ReAct 有个问题：容易陷入死循环，或者在某一步卡住。

我的经验是加两个约束：最大步数限制和关键节点人工确认。比如设置最多 10 步，超过就中断并提示人工介入。在“创建采购单”这种涉及资金的步骤前，强制弹窗让用户确认。

3.4 异常处理：当 API 挂了、数据错了怎么办

这是最容易被忽视但最影响体验的部分。Agent 在执行过程中可能遇到各种异常：API 超时、返回数据格式不对、库存刚好被其他人扣减了、供应商临时涨价等等。

我的做法是给每个工具调用都包一层重试+降级逻辑。重试就是失败后隔 1 秒再试一次，最多试 3 次。降级就是如果主数据源挂了，自动切换到备用数据源（比如缓存）。如果降级也失败，就返回一个结构化的错误信息给模型，让模型决定是告诉用户“系统繁忙请稍后再试”，还是尝试其他方案。

实操心得：错误信息不要直接抛给用户看，也不要让模型自由发挥去解释。最好预置几种标准话术，比如“库存系统暂时无法访问，已为您转人工处理”。这样既专业又不会让用户恐慌。

3.5 效果评估：怎么知道 Agent 干得好不好

上线只是开始，持续评估才是关键。我一般会盯三个指标：任务完成率、平均步数、人工干预率。

任务完成率就是用户发出的指令中，有多少被 Agent 完整执行了。平均步数反映的是效率，如果某个类型的任务平均要 8 步才能完成，那说明编排逻辑可能有问题。人工干预率就是有多少次需要人工确认或接管，这个指标太高说明 Agent 不够自信，太低又可能风险失控。

我建议每周拉一次数据，按任务类型分组看。比如“查库存”类任务的完成率应该接近 100%，而“采购下单”类任务因为有人工确认环节，完成率会低一些，但人工干预率应该控制在 30% 以内。

4. 实操过程：从零搭建一个类似的 Agent 系统

4.1 环境准备与工具选型

如果你也想复现一个类似 AutoClaw 的系统，我建议从最小可行版本开始。不要一上来就搞多 Agent、搞复杂编排，先用一个单 Agent 把“查库存”这个场景跑通。

技术栈方面，模型层可以用智谱的 GLM-4 或者类似的国产大模型，它们对中文和工具调用的支持都比较好。编排框架可以用 LangChain 或者自己手写一个简单的循环，我倾向于后者，因为依赖少、可控性强。后端 API 用 FastAPI 写几个 mock 接口就行，不用真的连数据库。

# 环境准备 pip install fastapi uvicorn requests pip install zhipuai # 假设使用智谱 SDK

4.2 定义工具与 Prompt 模板

先定义三个最基础的工具：查库存、查价格、创建订单。然后写一个 System Prompt，告诉模型它的角色、可用工具、输出格式。

system_prompt = """ 你是一个水产供应链调度助手。你可以使用以下工具： 1. query_inventory(species, spec) - 查询库存 2. query_price(species, spec) - 查询最新报价 3. create_order(species, spec, quantity) - 创建订单 规则： - 每次只调用一个工具 - 调用工具前先说明你的理由 - 如果信息不足，先向用户提问 - 涉及创建订单时，必须等待用户确认 """

4.3 实现主循环与工具路由

主循环的逻辑很简单：把用户输入和 System Prompt 一起发给模型，模型返回要么是普通文本（直接回复用户），要么是工具调用请求（执行工具后把结果再喂给模型）。

def agent_loop(user_input): messages = [{"role": "system", "content": system_prompt}, {"role": "user", "content": user_input}] for step in range(10): # 最大步数限制 response = call_llm(messages) if response.is_tool_call: tool_name = response.tool_name tool_args = response.tool_args result = execute_tool(tool_name, tool_args) messages.append({"role": "assistant", "content": response.raw}) messages.append({"role": "tool", "content": result}) else: return response.text return "任务步骤过多，已中断，请人工处理。"

4.4 联调与压测记录

跑通之后，我用 50 条真实业务话术做了测试。第一轮准确率只有 62%，主要错误集中在“规格理解”上——很多用户说“大只的”而不是“2斤以上”。后来我在 Prompt 里加了一个映射表，准确率提升到 89%。

压测方面，单实例 QPS 大概在 5 左右，延迟主要花在模型推理上。如果要做生产级部署，建议用异步调用+队列的方式，避免请求堆积。

5. 常见问题与排查技巧实录

5.1 模型“幻觉”出不存在的数据

这是最常见的问题。比如库存明明是 0，模型却回复“还有 50 斤”。排查思路：先看工具返回的原始数据，确认 API 没问题；再看模型是否在工具返回后做了“二次加工”。我的解法是在 Prompt 里加一句“所有数字必须来自工具返回结果，不得自行推算”。

5.2 工具调用参数格式错误

有时候模型会把数字传成字符串，或者把枚举值传成近义词。解法是在工具定义里加strict: true，并在执行前做一次参数校验，不合法就返回错误让模型重试。

5.3 多轮对话上下文丢失

如果用户先问“澳龙库存”，再问“那波龙呢”，模型可能忘记“库存”这个上下文。解法是在每轮对话开始时，把最近 5 轮的历史摘要注入 Prompt。

5.4 独家避坑技巧

我踩过最大的坑是：不要试图让 Agent 处理所有边界情况。有些异常情况（比如供应商临时毁约）涉及复杂的商务谈判，Agent 根本处理不了。这时候最好的做法是设计一个“转人工”按钮，让 Agent 明确知道自己能力的边界。这比强行让 Agent 瞎猜要靠谱得多。

另一个技巧是：给每个工具加一个“模拟模式”。在开发阶段，所有工具调用都返回 mock 数据，这样可以快速验证编排逻辑，不用等后端接口就绪。上线前再切换到真实模式。

6. 这个项目的影响范围与可扩展方向

AutoClaw 这类系统的影响范围其实远不止水产供应链。它的核心能力——理解自然语言指令、调用多个系统 API、完成多步任务编排——可以平移到很多场景。比如餐饮门店的自动补货、生鲜电商的智能客服、甚至制造业的物料调度。

我个人的判断是，未来两年这类“垂直领域 Agent”会大量涌现。通用 Agent 听起来很美好，但落地时你会发现每个行业的术语、流程、合规要求都不一样，通用方案根本搞不定。反而是像 AutoClaw 这样深耕一个场景、把工具链做扎实的项目，更容易跑出真实价值。

如果你正在考虑做类似的事情，我的建议是：先找一个闭环短、数据结构化、痛点明确的场景，用最小成本跑通一个单 Agent 流程。不要一上来就追求“大而全”，先把一个点打透，再考虑横向扩展。我在实际项目中最大的体会就是：Agent 的上限不取决于模型有多强，而取决于你对业务的理解有多深。模型可以换，但业务逻辑的梳理和工具的设计，才是真正拉开差距的地方。