导读海管家是一家专注垂直领域：国际物流的 Saas 企业，分享其在国际物流行业场景中，Agentic workflow 从静态流程向动态智能演变的探索与实践。
1. 物流行业挑战与技术演进
2. WOL-APL-EVAL架构设计
3. 海关场景实战案例
4. 试验性工程探索（Exp）
5. 工程化实践与未来展望
6. Q&A
分享嘉宾｜徐红维 海管家 CTO
编辑整理｜曾晓辉
内容校对｜郭慧敏
出品社区｜DataFun
01
物流行业挑战与技术演进
1. 行业背景
国际物流偏向于国际贸易，是承载整个国际贸易进出口的底层支撑。坐拥 30 万亿美元的市场规模，连接两端，一端连接源头厂家，一端连接买方，源头是工厂，买方是全球各地的消费者。国际贸易中，一票货从国内发货，到国外履约完成，整个周期差不多需要 15 到 20 天，涉及 10+利益相关方，其中 70% 的工作仍然依赖人工流程。尽管多年来数字化努力不断，航运本身已经优化，但跨利益相关方的信息流仍然分散；物流公司仍然难以用自动化解决方案替代经验丰富员工的精细决策能力；仍然受到运营效率低下的困扰，面临的主要挑战包括复杂的多方协调、跨境合规监管，以及持续依赖难以应对异常和变化的传统系统。
而海管家主要服务于国内源头端的节点生产企业，为他们提供线上化的 Saas 服务。海管家原先从实体物流开始，慢慢转变成互联网平台，做国际物流的 SaaS 平台服务，本质上是要把整个链条环节的数据信息要素流转起来，做好整体信息的治理。
2. 国际物流的业务流程
国际物流的业务流程，整个链条围绕着货的主体，货的物流，以及流转过程中上下游交互的数据，其中的关键是串联整个链条的数据并保持一致。
通常一票货会涉及到 8 到 12 个不等的参与方，其涉及到的业务环节非常多，涉及到非常重、非常麻烦的人工协调工作，要不停通过 Email、微信，或 QQ 等工具跟上下游确认信息，即时更新，保持同步与一致。而且不同参与方的信息化程度、业务规模、以及所承载的环节任务以及要求都是不一样的。
全球供应链跨境连接多个利益相关方，形成相互依存的复杂运营网络：具有多方参与者、文档处理负担重、人工异常处理协调时间投入大、成本高以及信息孤岛等特点与问题；其信息化、数字化主要是近几年才开始慢慢从原先的地面物流跑窗口，转移到线上处理操作。
3. 国际物流行业痛点分析
国际物流行业有个非常明显的痛点，其是人力密集型的行业，人工成本高达 70%，无形办公劳动的运营成本占到 30-40% 的比例，依赖大量坐在办公室的白领处理大量面单以及跟上下游各个节点沟通。
通常一票货从发货到履约收到货需要 15 天，但整个业务节点的流转、相关文档处理却要 20 天；作业工具，基本上还是以 Excel 为主。纵然有系统，系统也需要人把今年以及前几年的数据录进去，然后在系统里做流转；这部分工作对于从业者工作量大、枯燥无味。如在很多物流公司里通常能看到有那么一个角落用来存档堆放纸质面单。
概况起来主要有四方面的痛点：
传统工具（Excel、静态工作流）无法处理异常或政策变更；
信息孤岛导致重复工作和数据协调问题；
多方协调需要持续的人工干预；
被动故障排除而非主动预防问题。
4. 流程自动化的三代范式变迁
流程自动化，经历了三个周期，现正处于向第三个周期的范式跃迁。
第一个周期：RPA 机器人流程自动化，偏向于执行层面，RPA 本身是执行大于编排，一旦流程固化了之后，机械执行。其基于 UI 界面模拟人工操作，适用于重复性任务的自动化。
第二个周期：规则引擎+工作流编排；所谓的规则是你怎么去处理上下游的信息；但规则也分所谓的显性的规则和隐性规则，适合复杂流程编排、条件分支判断以及多系统协调。
第三个周期：AI Agent 智能自动化；AI 工作流编排偏向于在整个工作流引入智能体进行自主编排，像 Coze、Dift、Manus 等工具平台；适合动态决策、意图理解、自主规划和上下文感知等任务。
5. 从行业痛点到 AI 应用场景：能力匹配与实践路径
AI Agent 要落到行业里，得结合行业的 know-how，解决具体的问题。
在落地场景的选择上要衡量两个象限的能力以及场景的匹配度，纵轴是 AI 能力本身的发展，横轴是业务的复杂度问题。供应链场景位于右上角，流程复杂度以及对模型、应用厂商的 AI 能力要求都很高。
面对国际物流行业的现状问题：复杂性挑战、成本压力、合规风险以及时效要求。在能力匹配策略上要做以下的取舍：准度 VS 信度；单点能力 VS 全局能力；在技术选型上要结合场景的要求选择相应的技术路线，如高准高信场景优先规则引擎，结构化决策优先 ML；中准+HITL（人机回环）场景选择大模型。
02
WOL-APL-EVAL 架构设计
1. 解决方案原理
往 AI Agent 的范式转变中，解决方案的思路发生了相应的改变；从预设步骤转向目标导向，从传统的工作流向智能代理工作流演进。
原先是固定执行的规范，固定执行的约束，框定执行的范围，本质上是规范你的动作，但得到的结果未必是 100%，毕竟执行的结果不仅取决于动作的规范，往往也由输入决定；若你的输入有一点点的偏差，整个流程是不能跑完的，未必就能输出想要的结果。
海管家采用 WOL-APL-EVAL 架构，能够“动静结合”，平衡好“顶层流程固化”（WOL 层）与“底层动态规划”（APL 层）的边界。
2. WOL-APL-EVAL 架构
智能体的开发范式：规划、记忆，反思、推理；相当于是基于目标，大环节拆小环节，框定执行的步骤，框定你的约束，但执行下来的结果没有想象中的那么好，能够直接达到预期的效果。
在工程实践上，采用 WOL-APL-EVAL 架构，其是结合治理、适应性和持续评估的神经符号学方法，WOL 层负责定义“做什么”（目标、规则、约束），APL 层负责“怎么做”（自主规划与执行），EVAL 层负责持续评估目标完成度与风险。该架构的强大之处在于其集成：WOL 定义"做什么"（目标和边界），APL 决定"怎么做"（规划和执行），而 EVAL 通过实时性能监控和反馈确保持续改进。
WOL（流程治理层）：这一层扮演着“总指挥”的角色。它定义了整个业务流程的顶层框架、关键节点、合规要求、风险控制点以及高层业务目标。例如，它会规定“所有出口报关必须在离港前 48 小时完成”，“运输过程中，客户必须知晓货物状态更新”，或者“任何涉及金额超过X万的支付，都需要二次人工审批”。WOL 层是相对“静态”和“固化”的，它为整个系统提供了方向和约束。
APL（自适应规划层）：这一层则像“执行官”。它接收 WOL 层设定的目标和规则，然后利用 AIAgent 的能力，在这些框架内自主地规划具体的执行路径和动作。例如，当 WOL 设定了“在规定时间内完成订舱”的目标时，APL 中的 Agent 会去分析实时的舱位信息、价格、船期，自主选择最优的承运商和舱位，并完成订舱操作。
EVAL（评估模型层）：持续监控 Agent 执行过程中产生的各项数据，与预设的风险阈值进行比对。设计逻辑在于从“流程是否走完”转向“流程是否达成预期效果”。当某个指标接近或超过阈值时，系统会触发预警，甚至自动采取风控措施（如暂停 Agent 的某些操作，或通知人工介入）。
3. 架构图
对整个作业流程进行详细的拆解，每一个环节它都会涉及到内部、外部，涉及到上游、下游，每一个环节都可能会涉及回溯到之前的环节。对于 ToB 业务，每家企业可能业务类型、业务环节类似，但在业务的操作上有非常大的差异，有自己的风格、偏好；没有办法很好从非标化到标准化，一旦抽象到标准化之后，会有大量信息的丢失，流程细节的丢失，没有那么容易能达到基本生产可用的状态和效果。
用 agent 处理某单一环节，一个 agent 通常是不够的，需要引入多个 agent 进行协作完成。当下 MCP 已经出来有一段时间，AI 基于任务的理解选择对应的工具解决问题。在国际物流行业，主要就那几个工具，所以在工具的选择上，100% 衡量选择的准确性是完全没有问题的。海管家把其产品矩阵，每个业务环节相应的产品，封装成模型能理解的语义，让 AI 根据任务去选择、调用、处理任务，选择的准确率能达到非常高。
以通用单证识别为例，通过一些定制化手段和工作能达到 100%；企业可能会要求达到 100%，这是他的第一条件，当你能达到，还是免不了需要人去兜底检查，再确认对还是不对，更何况当下还达不到全流程的自动化。但对于用户来说，就算达到 100%，那可能也不是客户想要的，毕竟你的 100% 参照的是原始面单；若原始面单是错的，需在原始面单的基础上实现链条前后数据的逻辑校验；如第一个环节的面单填错了，往海关发送报关数据时，可回溯反过来再去校验前置的数据；其中的逻辑校验环节也并不一定就需要智能体来做。
国际物流的流程对应三层架构，架构可用于指导 AI 场景的落地，采用规则+智能+验证的方式，静态治理（WOL）+动态智能（APL）+持续验证（EVAL）＝可靠的智能工作流。
WOL 工作流编排层：负责顶层工作流编排，定义明确边界、确保可解释性并维护企业合规性的"静态"符号层；框定大的板块，但不框定任何一个细节，如生产端、运输端、海关端、派送端；大的环节在整个流程相对固定，所有货物出口都需要经历，不会差别太多。流程编排相对比较简单，是所谓的策略即代码工程理念的应用。
APL 自适应规则层：在 WOL 约束下提供适应性、上下文理解和自主决策的"动态"神经层；顶层业务流程提炼出来后，对应的业务规则、合规边界、安全防护通过对业务的理解、对流程的梳理可定义出来。多步工作流可根据客户的实际场景，去扩展、去扩充。APL 层类似于 agent 的自主规划，在真正进入到规划时，前置有一个条件，要去判断整个的业务本身的复杂度，以及数据的完整性；如数据不全，但这个步骤一定要走时，怎么去处理。
EVAL 评估层：通过持续监控和反馈循环，将关注点从"流程合规"转向"业务成果"的测量层。不能衡量，你就不能优化，上智能体，对于评估层，行业内基本达成共识，评估必不可少，必须做到非常细致。海管家从两个象限进行评估；一个象限是算法，用技术性指标进行衡量，如召回率、准确率；另一个象限是业务性指标，海管家把大量的评估工作放在业务指标这一侧。客户需要的是解决他的问题，带来价值，而不是一味的追求 100%、达到 100%；市场的客户是愿意为效果价值买单的。
4. 工作流对比
传统流程跟 agentic workflow 之间的一些差别，其更多是理念的差异，传统的流程偏向静态规则，比较固化；智能代理工作流有一定的自主性，容错性，有一定的的修复能力，可基于上下文去自主决策、去推理，专注于结果而不仅仅是流程。
5. WOL 工作流编排层
为什么需要 WOL，解决什么痛点？
规则分散、执行不一致，难以审计与追责；
合规边界不清，跨地区/跨系统风险高；
流程长链条，异常回退与人工干预成本高；
历史数据易失效，SLA 与成本难以兼顾。
WOL 层的核心价值：把整个流程框在一个合理的范围之内进行动态结合的混合智能代理执行。
策略即代码：把业务/合规规则固化为可执行策略；
端到端可控：从设计、实例化到执行全链路受控；
合规内置：运行时强制校验与审计追踪；
可量化：SLA、成本、一次解决率等指标闭环。
6. 从复杂业务到可编排流程
把整个业务的流拆到更细的颗粒度，进一步细化，所有业务的处理，所有数据的处理，基本上就是查询、比对、生成、检验、路由、通知等微任务的处理与组合，在 WOL 的目标规划以及过程任务处理中，能更好将 AI 的能力优势发挥出来，如非结构化信息提取、模糊匹配与归因、交互与状态解释。
其抽象化的方法论可概况为以下的几点：
分层再分段：物流与信息流分离，按业务里程碑切段；
里程碑+门禁：状态机建模，门禁规则控制状态转换；
微任务原语：查询、比对、生成、校验、路由、通知；
隐性知识显式化：以 Policy-as-code 固化规则。
其中的核心原则：AI 作为"算子"提供建议，不直接驱动状态跃迁；状态跃迁由门禁规则决定。
7．APL 自适应规划层
APL 自适应规划层，其更多是在既有的框架之下去做自主执行与执行，框住你，不允许自由发散，对于提示词会有非常多的一些限定，对上下文的管控有非常多的限定与隔离，限度约束这一层的流程节点，不会发散漂移到其他的知识象限里去。
任务复杂度评估器是 APL 层的核心创新，能够实现任务复杂度分类、WOL 控制下的自主规划、张弛有度的执行策略，在 WOL 的控制范围内实现自主规划，平衡效率与可靠性。
其核心原则：APL 在存储、工具调用、反思和计划方面借鉴了标准 Agent 框架，其关键创新在于用任务复杂度评估器筛选合适的执行路径，从而避免大模型幻觉。
8. EVAL 评估模型
EVAL 是业务信任的基石，business first，业务评估要优先，聚焦业务，持续将技术指标转化为业务价值；其通过双层指标体系、实时反馈闭环以及风险控制机制来搭建评估模型。
双层指标体系：技术→业务映射；将技术指标通过映射关系转化为业务 KPI，使技术价值可见可量。
实时反馈闭环：持续改进引擎；构建实时监控→告警→优化触发→验证效果的完整闭环，确保系统持续优化。
风险控制机制：安全创新平衡；通过金丝雀部署+A/B 测试确保新策略先小范围验证再全量推广
其核心原则：Business-First 评估哲学，WOL 定义"规则"，APL 实现"智能"，而 EVAL 证明"可靠"。以业务场景指标为北极星，用业务语言而非技术术语建立信任。
03
海关场景实战案例
1. 实战案例：海关商品出口审单流程
海关审单是国际贸易中的关键环节，涉及多项合规要求、复杂规则和高风险评估，对准度、信度的要求非常高。
传统审单流程面临以下挑战：
合规压力大：超过 30 种不同监管模式，法规更新频繁；
时效性要求高：24 小时内完成审核，影响货物放行时间；
异常处理复杂：约 15-20% 的单据存在各类异常情况；
海关审报关单的第一优先是合规不出错，整个审单流程编排拆解下来，总共 17 个步骤，里面将近 50 个字段，按照字段的域，按照字段的属性，拆出 17 个步骤，这 17 个步骤偏向于经验驱动，规则比较模糊。
2. WOL 工作流编排：策略即代码的双主轴治理
WOL 将海关监管规则编码化，实现"策略即代码"理念，确保复杂多变的监管要求能够以结构化形式执行与追溯。
其具体通过对整个流程进行治理，将海关监管规则编码化，实现"策略即代码"理念，实现程序/一致性轴与产品/合规轴的双轴治理，以及门禁规则机制、并行编排机制、智能分流机制，确保复杂多变的监管要求能够以结构化形式执行与追溯。
3. 策略即代码工程
策略即代码工程：整个流程的编排，并没有采用所谓的可视化拖拽的方式，而是采用代码编排的逻辑来做；如整个流程，一个阶段流程的执行需要哪些东西，前置校验是什么，后置的校验是什么，异常怎么处理，关联的资源，把它作为知识的输入，任务的上下文进行代码编排。
Policy as Code 核心理念：将业务规则和监管逻辑转化为结构化提示词模板，实现规则治理与AI大模型能力的完美结合，兼具可追溯性与灵活性。
Progressive Disclosure 设计模式：采用三层上下文管理机制，使大模型根据任务需求动态加载关联资源，避免上下文窗口浪费，提高决策精准度。
上下文窗口优化策略：结合触发条件和门禁规则，实现任务分流与精准导航，保证模型处理复杂海关审单逻辑时的上下文相关性。
4. APL 自适应规划与人机协同决策
在海关审单流程中，APL 层负责动态规划和智能决策，解决了传统工作流无法处理的复杂场景和异常情况。
在 APL 层嵌入任务复杂度评估器、HITL 决策机制以及反馈迭代优化机制；将程序一致性审核与产品合规性审核路径的结果进行融合，融合验证与风险综合，生成全面风险评分，指导后续处理优先级和深度。
任务复杂度评估器：实时评估单证审核任务复杂度，判断是否需要人工介入或自动完成。
HITL 决策机制：在合规性审核中识别需要专家判断的边缘案例，动态调整决策路径。
反馈迭代优化：从人工审核结果中学习，持续提升自动化流程的准确性和合规性。
APL 层引进了人机协同的机制，流程划分好了后，要用到 AI Agent 去做 APL 的环节，整体也不到百分之二三十，更多是在策略层即可完成。80% 的任务通过流程、策略的方式帮你解决完，剩下的 20% 是知识密集型的任务，判断 AI 推理出来的东西，从准度、信度、置信度不够时，精准触发跟人的交互，人来做最终业务以及数据的兜底。
5. 场景介绍-海关 HS 编码 GRI 归类的复杂性挑战
以中国海关对于商品出口归类的六类原则为例，描述非常官方，AI 压根不知道从里面能抽取出什么样的规则出来，本质上它是法律解释，不会明确的告诉你的商品为什么归到这类。
6. 商品归类挑战与传统工作流失效深度分析
商品归类问题传统工作流因静态规则失效、无法动态调整、人机边界模型以及无法学习优化等问题逐渐失效，商品归类面临模糊性与冲突性挑战：
产品复杂度增加：现代商品融合多种功能与材料，跨章节特性日益普遍，传统单一功能商品分类方法失效。
GRI 规则模糊性："从一般到特殊"、"基本特性"等关键术语缺乏精确定义，不同解释可能导致完全不同的归类结果。
专家判断依赖：高度依赖海关专家经验判断，5-8 年培养周期，知识传承困难，主观一致性难以保证。
如智能手表归类冲突案例：同一款智能手表，不同专家可能归为 91 章(钟表类)或 85 章(电子设备类)。GRI 规则 3(b)要求判断“赋予产品基本特性的组件"，但"基本特性"认定存在主观性。
海关 HS 编码 GRI 归类这类问题处理非常依赖人类的经验判断，认定存在主观性。我们把整个规则重新做了非常详细的梳理跟拆解，目前梳理出含 1 万多商品的 code，包括它的注释、法律条文，做了结构化的梳理，让模型能够看得懂、理解得了，并通过知识库的方式化解商品分类的模糊性和冲突性问题，执行路径通过历史库、案例库找到后人再去匹配、分类，商品分类的效率和准度大大提高。
7. APL 自适应规划解决方案-三层智能决策机制
整体架构引入了任务复杂度评估→策略自适应→人机协同三层智能决策机制：
核心机制 1：任务复杂度评估器，5 级自适应回退搜索策略
核心机制 2：HITL 精准触发-多维度风险评分系统
核心机制 3：反馈迭代优化-知识增强架构(渐进式演进)
最终整个流程83%实现自动通过，17% 触发 HITL。
8. EVAL 评估指标（业务指标）
EVAL 层在海关审单流程中实现全程评估与反馈闭环，确保每一环节的决策质量与效率。系统通过关键指标实时监控，持续调优模型表现，为智能代理赋能。
在双主轴审单流程中，EVAL 不仅评估最终结果，更对每个节点的表现进行实时验证：
单证首次通过率监控
异常识别准确性
跨系统一致性检查
EVAL 的持续评估确保 WOL 编排的流程与 APL 的自适应决策在实际业务中高效协同；其闭环反馈机制确保系统在复杂的海关监管环境中持续自我优化。以出口环节为例，整个合规判断准确率达到 93.6%，处理效率提升 4.2X，人工审核时间减少 68%，月度持续优化率 +1.8%，目前关键绩效指标处于行业领先水平。
9. EVAL 评估指标（技术指标）
关键技术指标成效：Overall Accuracy：94.7%；Avg Processing Time：3.2min；Human Intervention Rate：8.3%。
技术指标评估其关键在于评估模型的思考过程能不能把整个上下游的数据串联起来，实现闭环。
10. 渐进式演进架构路线图
架构经过了多轮次的渐进式演进，从基础框架到向量检索到知识图谱到混合智能，以零重构策略实现平滑能力提升，确保系统稳定性与可扩展性
先从一个最小的试验单元，慢慢开始往上增量拓展，一开始通过全文、关键词，后面通过向量，再拓展深化为图谱；目前虽然看似只有 1 万多条数据，但扩散开来也是非常庞大的图；有了图谱后再进行召回，给到模型，准确度能更准确。
其架构渐进式演进设计原则：接口抽象+Schema 预留+配置驱动。
04
试验性工程探索（Exp）
1. 试验性工程：Shadow Workflow（Exp）
Shadow Workflow，通过数据采集—轨迹重建—规则抽取—专家验证—规则应用—规则治理等步骤解决冷启动的问题。
数据采集把数据留存下来，基于这些数据，先人工去筛，再把这些数据给到模型，让它去 learning、提炼；基于上下文的数据，再结合规则库，反向推理出来再推给前端的用户，让他去确认这是不是你当时归类的逻辑？调整、确认完后，再提交补充到模型的上下文，再验证持续迭代优化。
核心价值
隐性知识显性化：自动捕获专家决策过程，将无形经验转化为可见规则；
专家经验自动沉淀：从个人经验到组织知识资产，避免人员流动导致的知识流失。
预期效果：
知识迁移效率提升：从传统师徒制到系统化规则库，专家培养周期的缩短；
经验可复用性：结构化规则可直接注入 AI 系统，实现知识资产自动化应用。
2. 试验性工程：Prompt Learning（Exp）
试验工程：prompt learning，其来源于 AI CODING 的处理，AI CODING rules 要编排什么规则，让模型产生的代码质量高，上下文的窗口能够尽可能压缩。因为窗口意味着成本问题。
其是把全部链路的提示词上下文数据给到模型，让它再优化一遍，优化完了后再做交叉分析，再合并到主干的分支里，当前对于结果的衡量目前主要还是通过人去看，它相当于是后置优化迭代的工作。
05
工程化实践与未来展望
1. 经验教训与最佳实践
成功经验：
prompt Engineering 优先：海管家采用 721 的模式，70% 通过 prompt，20% 调一些小模型，10% 训练模型，目前训练的 32B 模型，能够处理国际物流的绝大部分场景和任务。
数据优于算法：从第一天开始就要去琢磨你的数据。很多企业觉得自己有数据，但那个数据根本不称之为数据。先积累高质量数据资产，再优化算法复杂度；先搭建数据积累框架，积累 100+ 案例后再优化算法效果会更直接、更好。
接口稳定优先：接口先行，实现可以渐进，避免反复重构；MVP 定义稳定接口，快速实现基础策略，后续零影响扩展。
踩过的坑：
过度依赖 LLM"智能"：不要过度依赖模型的能力，它可能在发展，你的第一要务是解决客户的问题，你第一要务是把你的产品卖出去，不要试图将所有复杂度丢给大模型处理。
忽视中文 NLP 特殊性：照搬英文方案，不考虑中文分词等特性，导致检索效果差。
架构不考虑演进：没有预留扩展点，技术债累积，每次升级都要推倒重来。
2. 大模型应用工程化的四大支柱
大模型应用工程化的四大支柱构成了完整的方法论体系：
第一是成本的问题，你的成本到底足不足够支撑客户省一票单子，到底是 5 块钱的成本还是 10 块钱的成本，能够帮客户省多少。通过渐进式披露和知识模块化显著降低 Token 消耗，提升系统效率。
第二是鲁棒性的问题；通过多级 Fallback 和 AI 兜底机制确保系统稳定性和高可用性；
第三是可演进性问题，不要觉得做一个 MVP 产品是简单的几行代码就搞定，你要考虑后续能够去叠加、去扩展；能不用框架，就先不用框架；成型后再用框架，会更快；若一开始就上框架，早期有可能会很快，但会被框架框住，不利于后续的扩展。通过接口抽象和 Schema 预留实现零重构演进，降低系统更新成本。
最后是可追溯性问题，其是黑盒到白盒的过程，你要知道它不好的点在哪里，比如说这个字段识别不准，你要告诉我为什么识别不准？你要把整个上下文的链路信息全部给到以便追溯定位问题。通过结构化推理和证据链确保决策透明，满足合规要求。
四大支柱相互支撑，共同构建可靠、高效、可持续的大模型应用工程化体系。
3. 经验总结
一是平衡静态规则与动态 AI；在静态规则跟动态自主规划做平衡，不要过度去追求全流程自动化。静态治理必须提供明确边界，同时允许 LLM 代理具有足够的 自主适应能力。这种平衡因行业风险特征而异。
二是注重可靠性工程，至少要保证能够把一个业务流程跑完，而不是推理到 10 步、20 步，然后不行。优先考虑健壮的错误处理、回退机制和明确的评估指标，而非模型的复杂性。生产环境中的 AI 首先需要的是稳定性。
三是人机协同，人机协同会持续一段时间。特别是 toB 的业务场景。有效的反馈机制和明确的升级路径确保 AI 系统保持问责性，并从人类专业知识中持续改进。
最后是领域知识的集成，检索增强生成（RAG）和行业特定知识库显著提高智能代理系统在专业领域中的效果。对于领域知识用专业的向量库，现在用的是支持图谱、支持传统行列结构，支持向量检索的融合库。
4. 实用建议
从有界试点开始-在扩展到更广泛应用之前，先从定义明确、可衡量 KPI 的有限领域起步。不要一上来就搞一个你自己觉得都不行的一个点。
优先考虑可解释性-确保智能代理系统做出的决策可以被技术和非技术相关人员追踪、理解和审计。AI 写出来的代码如果你看不懂直接采用是有问题的，所以在这个里面就是模型给出到的响应跟反馈，怎么去解释它？一定要能够去验证它。
构建混合安全系统-将大语言模型与传统规则引擎相结合，减少幻觉并确保合规护栏。
标准化人机交互接口-设计一致的协议，规范代理如何接收指令、请求澄清和与人类操作员协作。
实施反馈循环-设计能从结果和人类反馈中持续学习的系统，随时间推移提高性能。一定要有实时反馈，不要让它是黑盒状态在运行，一定要能够看得到它做了什么，看到整个系统的数据、用户的反馈。
整合领域知识-通过特定场景工作流专业行业知识、分类法与业务逻辑的喂养下的代理能力增强。
06
Q&A
Q1：整体工作流 80% 用静态配好的规则，20% 用 AI 自主规划来处理一些环节和工作，哪些环节是自主规划的？
A1：本身描述非常模糊的情形，如海关的六条归类原则；这个原则单独讲非常难以讲清楚，必须要结合真实的场景案例来讲解；因为它是法律意义上的解释，实际不能直接落到真实的业务场景，比如遥控器怎么归类？它带不带无线电功能，还是带其他的一些功能，这种情形可以归到玩具，也可能归到通讯设备。在这样模糊情形下，没有办法用静态的规则把它框住。
Q2：做 AI 应用是重新搞一套，还是在原有的系统之上进行叠加、拓展应用？
A2：海管家的国际物流 Saas 应用是建立在中国海关的基础合规性框架之上，在法律意义上数据叠加自己平台积累的数据去做应用。很多客户上来第一件事是就要盲测，其中的 shadow workflow 解决冷启动的问题；我们会先引导客户先使用我们的系统，并把 AI 应用集成到 Saas 服务中来综合解决业务问题。
Q3：在可解释性和用户交互方面，做过哪些优化让人机协同更好一些？
A3：当时最大的一个争议分歧是什么样的环节需要用户来确认、来把关；毕竟数据一旦提交到海关，若你的数据有异常，是有罚金的，会触发它的查验，后续会有对应的处罚，那这点就是触发人机协同的关键风险点；还有数据缺失的情形，若流程不能继续往下走，此时需要人介入参与进来。目标是要提效、要降低企业的运营成本，若 17 个流程有 15 个流程都还需要人去干预、去兜底，客户是不会为此买单的。整体的方法是尽可能识别触发关键风险的点进行介入兜底，比如涉及到财务跟钱的事情；比如数据缺失的流程，先让 AI 判断，设定提示词框定它，当发现有数据缺失时，拉起来跟人进行交互，让它重新回到流程的回路去执行；它不是一个 chat 的模式，而是偏向于将藏在业务后面的逻辑进行折叠，将 AI 融合到流程里。现在通用智能体没有办法替代业务系统，但系统可转变为流程可视化的界面，原先偏向业务操作，现在系统侧重追踪与回溯，模型有自己的推理逻辑，要把这种工具类的调用、任务的处理转化成业务的语义，转化成用户能看得懂的逻辑。如检验的金额对不对？回退到系统告诉它是检验商品价格合理性问题，再加上外部引用参考案例的知识增强，这样过程可解释、可溯源，用户的信任会越来越高。