企业级 Agent 生产落地：从业务架构到技术基建的体系化思考

企业级 Agent 生产落地：从业务架构到技术基建的体系化思考

做企业级 Agent 落地，见过太多团队从「Demo 惊艳」走到「生产难产」。 也很清楚很多人刷到这类体系化文章的第一反应：架构图画得很漂亮，但太重了，小团队根本玩不起，属于大厂中台的自嗨。

确实，如果上来就照着全量架构一步到位，别说中小公司，大厂非核心业务线都扛不住。但反过来，只靠 Prompt + 向量库 + 简单编排，也永远跨不过 Demo 到生产的坎。这篇的价值，不是让你立刻照着搭一套全量系统，而是给你一张完整的地图：你知道终态长什么样，知道哪些是核心必选项，哪些可以按需裁剪，也知道哪些坑迟早要踩、该怎么绕。

这篇文章篇幅较长，定位是工具型参考手册，适合收藏后按项目阶段反复翻阅。为了帮你快速定位内容：

• 如果你在做技术选型，可以直接看第四章的 L4 编排层，那里有 LangGraph 与 Temporal 的选型对比；
• 如果你正在处理长流程、幂等和异常恢复问题，可以直接跳到第七章的脏活实操；
• 如果你在规划项目节奏，可以重点看第六章的三阶段路径和生产自检清单；
• 如果你想完整理解这套架构的设计逻辑，建议按顺序阅读。

需要说明的是：本文提出的十二项业务能力与九层技术架构，并非某个组织发布的统一行业标准，而是我基于企业 Agent 落地经验、主流工程实践和传统企业软件架构方法做的一次体系化归纳。它更适合作为项目规划与架构检查的参考地图，而不是要求所有团队完整照搬的标准答案。

结合业内两套被广泛引用的成熟框架思路，再加上多个项目踩过的实坑，我从架构视角拆解从业务设计到技术实现的完整路径，也专门聊聊那些教程不会写、但落地必遇到的「脏活」怎么干。

一、顶层认知对齐：企业 Agent 的架构本质

在谈具体框架之前，先明确三个底层判断，这是所有架构设计的出发点：

1. Agent 的核心价值是「行动」，不是「回答」。只能输出文本的是对话机器人，能调用工具、操作系统、推进流程的，才叫企业 Agent。
2. Demo 和生产的差距不在模型，在工程体系。原型只需要验证模型能做什么，生产需要保证系统稳定、合规、可控、可迭代、可兜底。
3. 落地必须双轮驱动：业务架构 + 技术基建。只谈业务不谈技术是空中楼阁，只谈技术不谈业务是技术自嗨，两者必须逐层映射、对齐设计。

二、贯穿示例：差旅报销智能体场景定义

为了让两套框架的拆解更具象，全文以企业差旅报销智能体为统一落地示例，先对场景做基础定义，不熟悉财务共享场景的读者可以先建立整体认知。

差旅报销是企业内部最高频的财务流程之一，核心是员工因公差旅产生交通、住宿、餐补等费用后，按企业管理制度完成报销申请、多级审批、财务审核、资金支付的全链路闭环。

• 传统全链路流程：员工整理纸质 / 电子发票→手动填报报销单并匹配出差行程→对照职级标准自查合规性→提交至部门经理审批→财务岗完成发票验真、额度校验、预算核对→财务复核→出纳打款；驳回场景需员工修改后重新走完整流转链路。
• 行业普遍痛点：员工侧填报成本高、规则不透明导致反复驳回，平均一笔报销耗时 30 分钟以上；财务侧 80% 工作量集中在机械的发票核验与规则校验，人力投入大且不同审核人员的标准执行存在偏差；管理侧预算管控滞后、合规风险难前置，事后审计成本高。
• Agent 落地目标：打造端到端的差旅报销智能体，员工仅需上传发票影像，系统自动完成发票信息提取、单据结构化生成、合规性校验、预算实时占用、审批流推送；绝大多数标准化单据实现全自动处理，财务仅需介入异常与高风险单据，能够显著降低员工填报与财务机械审核的工作量。

后续所有业务能力与技术基建的拆解，均围绕该场景展开，对应到具体模块的职责与落地动作。

三、业务架构视图：十二项核心能力，构建 Agent 业务能力闭环

从业务架构视角看，企业 Agent 的能力体系可以拆解为十二项核心能力。这十二项能力并非平铺罗列，而是按系统逻辑分为纵向主链和横切支撑两类 —— 前者解决「系统能不能干活」，后者解决「能不能在企业里合规运转」。每一层都有明确的架构定位、设计边界，以及对应的落地优先级和裁剪规则。

（一）纵向能力主链：从指令到进化的六层递进

纵向主链遵循「输入 — 决策 — 执行 — 迭代」的系统逻辑，能力逐级封装、层层递进。

1. Prompt 工程：人机交互的契约层

很多人把 Prompt 等同于「写话术」，这是最基础的认知偏差。从架构视角看，Prompt 工程的核心是定义模型的行为契约：明确角色边界、输入输出规范、约束条件、禁止事项，本质是给模型定「接口协议」。 它解决的不是「怎么让模型答得好」，而是「怎么让模型的行为可预期」。

场景对应：定义报销助理的职责范围、输出字段标准、超标判定规则、禁止越权操作项，相当于给模型下发了一份标准化的岗位说明书，从源头降低行为不确定性。 落地优先级：P0

【裁剪提示】所有场景必做。边界定义是模型行为可控的基础，无法绕过。

2. Context 工程：决策的信息边界层

Context 的核心设计原则是「按需注入、最小够用」。它不是把所有信息都塞给模型，而是精准提供决策所需的业务数据、规则与状态，同时严格控制信息边界，既是防幻觉的第一道防线，也是数据合规的关键节点。

场景对应：员工发起请求时，精准注入其对应职级的住宿交通标准、部门剩余预算、当前单据已提交材料，而非全量推送公司所有制度。 落地优先级：P0

【裁剪提示】所有场景必做。信息供给精准度直接决定幻觉率，没有替代方案。

3. Skill 工程：原子能力的复用层

架构设计的核心思想是「稳定能力下沉、可变逻辑上移」。Skill 工程就是把高频、稳定、通用的操作，封装成标准化、可版本化、可权限管控的原子能力单元，从模型的黑盒逻辑中剥离出来。 带来的直接收益是：能力可跨场景复用、可独立优化、故障可隔离。

场景对应：将发票 OCR 提取、报销额度校验、预算余额查询封装为独立 Skill。不仅报销场景可用，后续采购申请、对公付款等场景也能直接复用，识别准确率优化也无需改动业务逻辑。 落地优先级：P0

【裁剪提示】单一场景、单步操作的极简 Demo 可暂时不封装，进入生产后建议优先做，否则代码会快速腐化。

4. Agent 工程：任务的决策调度层

Agent 的核心职责是「规划与决策」，而非「执行」。它接收任务目标，拆解执行路径、调度 Skill 与工具、处理分支与异常，遵循「决策与执行分离」的架构原则。 判断一个 Agent 设计是否合格，就看它会不会处理异常：缺材料怎么办、校验不通过怎么办、接口超时怎么办，而不是只会走正常流程。

场景对应：收到报销请求后，自主规划执行顺序：先识别发票→再校验额度→超标则提示补充说明→缺件则通知用户补传→全部通过则生成单据推送审批，全程动态调整路径。 落地优先级：P1

【裁剪提示】单步线性任务（比如纯问答）可省略，涉及多工具调用、分支判断的复杂任务建议做。

5. Harness 驾驭编排工程：全系统运行时中枢

这是整个业务架构的核心底座，所有能力、数据、流程、安全最终都要收敛到这一层。它不做具体业务决策，只负责全链路的运行管控：请求接入、权限校验、模型路由、状态持久化、失败重试、降级熔断、人工兜底、流程推进。 可以说，Harness 是 Agent 系统从「脚本玩具」走向「生产系统」的标志。没有这一层，所有模块都是零散的组件，拼不成稳定运行的系统。

场景对应：串联从用户发起到审批推送的全链路；OCR 接口失败自动重试 2 次，预算系统超时自动降级为人工审核，所有中间状态持久化存储，系统重启流程不丢失。 落地优先级：P1

【裁剪提示】纯对话、无状态的 Demo 可省略，只要涉及工具调用、流程推进，生产环境建议做。

我们用一张表把Agent 智能体工程与Harness 驾驭编排工程的权责彻底划开：

你可以把整个系统比作一个剧组：

• Agent = 导演：只负责创作层面的决策 —— 这场戏先拍哪个镜头、演员怎么演、情绪对不对、过不过。
• Harness = 制片主任 + 场务：负责整个剧组的运行 —— 场地调度、设备协调、演员档期、出了意外找替补、拍一半下雨了改方案、全程记录拍摄进度。

导演再厉害，也管不了场地停电、设备坏了、演员临时爽约；而制片主任不懂拍戏，但能保证剧组每天都能正常开工，出了问题能兜底。 没有导演，拍不出好戏；没有制片，导演的想法根本落不了地，随便出点意外就全剧组停工。这就是 Agent 和 Harness 的关系。

一句话总结：Agent 只负责「想清楚要做什么」，不负责「真的去做、做失败了怎么办、做的过程怎么留痕、权限够不够」—— 后面这些脏活累活，全是 Harness 的事。

6. Loop 闭环工程：系统的演进动力层

这是智能系统与传统软件的核心区别：传统软件上线即定型，智能系统上线才是优化的开始。Loop 工程负责建立「反馈采集 — 问题诊断 — 规则迭代 — 效果验证」的闭环，让系统随业务数据积累持续自优化。 没有闭环的 Agent，上线就是天花板；有闭环的系统，效果会随时间持续爬坡。

场景对应：定期拉取财务驳回单据，定位高频驳回原因（如发票备注栏漏识别、出差天数计算错误），反向优化对应 Skill 的识别规则与 Agent 的校验逻辑。 落地优先级：P2

【裁剪提示】试点初期可用人工复盘替代，稳定运行、数据量积累后建议补全，否则系统效果会长期停滞。

（二）横切支撑体系：生产级落地的六大底座

纵向主链决定了系统「能不能干活」，横切支撑决定了系统「能不能在企业里合法、合规、规模化地干活」。这是 Demo 团队最容易缺失的部分，也是生产落地的核心门槛。

7. Data 数据工程：数据质量的底层保障

所有智能决策的前提，是输入数据可信。数据工程负责数据源治理、权威性判定、清洗标准化、去重纠错、敏感信息脱敏，是 Context 层的上游供给底座。垃圾数据喂给再强的模型，也出不来靠谱结果。

落地优先级：P1

【裁剪提示】纯公开数据场景可简化，接入企业私有数据建议做基础的清洗与脱敏。

8. Ontology 本体工程：业务语义的统一语言

这是最容易被技术团队忽略、但影响最深远的一项能力。它负责对业务实体、关系、规则做标准化定义，打通不同系统间的语义歧义，是跨系统集成的基础。 很多 Agent 接了一堆系统却数据对不上，根源就是跳过了本体建模，直接做数据对接。

场景对应：统一定义「报销单」的实体属性与字段含义，映射 OA 系统的「申请单」、财务系统的「支付凭证」、预算系统的「费用占用单」，确保三个系统说的是同一个业务对象。 落地优先级：P2

【裁剪提示】单系统、单部门试点可暂时跳过，接入 2 套及以上业务系统前建议补全，这是多系统集成阶段最常见、也最容易被低估的卡点。

9. Process 流程工程：业务闭环的骨架

这里必须明确一个架构原则：Agent 是流程节点的执行者，不是流程的定义者。不要试图用 Agent 替代 BPM，Agent 负责在单个节点里智能干活，Process 负责定义整条业务链路的流转规则、角色职责、审批条件、异常回流。Agent 不负责流程流转，而是通过标准化接口（如 REST API、消息队列）接收流程引擎下发的任务，执行完后将结果回写，由 BPM 继续推进。 这是 Agent 从「能做事」到「能进企业正式流程」的关键一跃。

场景对应：定义「员工提交→分级审批→财务初审→复核打款」的完整流程，明确金额阈值对应的审批人、驳回回流路径、超时处理规则，Agent 只负责在初审节点做智能校验。 落地优先级：P1

【裁剪提示】纯工具辅助、不进正式审批流的场景可简化，要嵌入企业正式业务流程建议做。

10. Evaluation 评估工程：迭代的客观度量衡

没有量化评估，所有优化都是凭感觉。评估工程建立离线评测、在线监控、人工抽检三级体系，用量化指标判断系统效果、验证迭代收益、发现劣化问题。 核心原则：评估指标必须对齐业务结果，不能只看技术指标。发票识别准确率再高，但报销一次通过率没提升，就没有业务价值。

落地优先级：P1

【裁剪提示】试点期可简化为核心指标人工统计，生产迭代建议建立标准化评测体系。

11. Safety / Governance 安全与治理工程：风险的刚性边界

Agent 具备行动能力，就必然带来操作风险。安全治理负责划定权限边界、数据安全、合规要求、责任归属，能力越强，管控越严。 架构设计上必须遵循「默认禁止、按需授权」原则，高风险操作强制人工二次确认，所有操作全链路留痕。

落地优先级：P0

【裁剪提示】只要涉及企业数据与系统操作，就是刚性要求，无法省略。

12. Product / UX 工程：用户信任的载体

技术能力再强，用户不敢用、不会用，价值就为零。产品体验工程负责把底层技术能力转化为用户可理解、可操作、可信任的交互形态，核心是建立用户对智能系统的信任。

场景对应：报错不说技术错误码，说人话讲清哪里不合规、怎么改；审批进度可视化展示；提供一键转人工入口，降低用户的失控感。 落地优先级：P1

【裁剪提示】内部技术人员自用可简化，面向全员推广建议做，否则渗透率会极低。

四、技术架构视图：九层 AI 基建，分层解耦的技术支撑

如果说十二项能力定义了「业务要做成什么样」，九层 AI 基建就回答了「技术上怎么实现」。这是一套典型的分层技术架构，每一层职责单一、独立演进、可替换，是复杂系统的标准设计范式。

每一层我都会标注主流选型、适用场景和选型建议，方便大家按需取舍。

（一）纵向九层技术栈：从算力到应用的分层实现

L0 基础资源层：算力与基础设施底座

解决「系统跑在哪」的问题，是所有上层能力的物理载体。企业级场景的核心诉求不是算力强弱，是多租户隔离与资源弹性调度，保障不同业务线的数据物理隔离、算力按需分配。

• 主流选型：K8s + GPU 节点调度、云服务商弹性算力、私有云部署
• 选型建议：中大型企业私有化部署、多业务线共享算力需要重点关注；小团队直接用云服务 API，完全不用关心这一层。

L1 模型与推理层：异构模型的统一调度层

核心组件是模型网关 + 推理引擎，解决「多模型怎么统一管理、怎么降本增效」的问题。 生产级部署的标准配置是：统一网关接入所有模型服务，基于任务类型、能力要求、成本、延迟做智能路由；配合推理优化、缓存复用、自动降级，在效果与成本间找最优解。

• 主流选型：LiteLLM（轻量首选，开源免费）、Portkey（商用全功能）、vLLM（自建推理引擎）
• 选型建议：10 人以下团队、单模型场景直接用官方 API；多模型、多场景建议上网关，否则后续切换模型、成本核算会非常痛苦。

场景对应：简单的额度校验、单据生成路由到轻量开源模型，复杂的异常判定、规则解读路由到大模型，能够显著降低简单任务的平均模型调用成本。

L2 数据与知识层：企业知识的工程化供给

核心是完整的 RAG 管道工程，不是接一个向量库就叫 RAG。从数据源解析、分块策略、向量化、索引构建，到混合检索、重排序、结果注入，每一个环节都影响最终准确率。 架构演进路径通常是：朴素 RAG → 高级 RAG → Agentic RAG，逐步提升复杂知识的处理能力。

• 主流选型：向量库 Milvus/Qdrant/pgvector、解析工具 Unstructured、重排序 BGE-Reranker
• 选型建议：中小团队、数据量百万级以内，pgvector 足够，无需单独部署向量集群；数据量大、并发高再上 Milvus 集群。

L3 Prompt 与上下文层：输入的工程化管理

把 Prompt 从零散的文本，升级为可管理的工程资产，也就是 PromptOps。核心能力包括版本管理、A/B 测试、发布审批、上下文拼装、Token 预算管控。 当系统里有几十个场景、上百套 Prompt 时，没有工程化管理，很快就会陷入混乱。

• 主流选型：PromptLayer、LangSmith、自研版本管理
• 选型建议：初期用 Git 管理 Prompt 文件即可，场景超过 5 个再上专业工具。

L4 编排与 Agent 层：有状态的流程调度

这是技术栈的调度中枢。Demo 级应用用简单链式编排就能应付，生产级系统建议优先采用有状态的图编排引擎，支持循环、分支、并行，更关键的是支持状态持久化、中断恢复、故障回溯。 对于包含多分支、中断恢复、长事务的流程，图编排是更稳妥的选择；如果流程固定、无分支且不涉及长事务，传统状态机或任务队列也够用。 一个判断标准：流程跑一半系统重启，能不能接着往下走？不能的话，就还没达到生产级的稳定性要求。

主流选型与核心差异对比如下：

最简实现对比（感受工程成本差异）

LangGraph 持久化配置（PostgresSaver）：

from langgraph.checkpoint.postgres import PostgresSaver # 1. 初始化持久化存储，一行接入 checkpointer = PostgresSaver.from_conn_string("postgresql://user:pass@db:5432/agent") checkpointer.setup() # 2. 编译图时传入，自动获得状态持久化、中断恢复能力 graph = workflow.compile(checkpointer=checkpointer)

Temporal Activity 定义（天然幂等 + 重试）：

@activity.defn def verify_amount(reimburse_id: str, invoice_data: dict) -> dict: # 框架自动保证幂等、重试、超时控制 return finance_client.check_amount_limit(reimburse_id, invoice_data)

• 选型建议：从技术最优解来看，报销这类跨审批、长周期、对接多业务系统的流程，优先考虑 Temporal。但选型前需要评估团队的运维能力：Temporal 需要独立的 Worker 集群和持久化存储，运维门槛更高；中小团队如果无人力维护分布式工作流引擎，LangGraph + PostgresSaver 也能支撑绝大多数报销场景，只是幂等、异常恢复和长流程管控需要自行编码实现。

场景对应：审批流程可能持续数天，必须持久化每个节点状态，系统升级、重启都不影响流程推进。

L5 工具执行层：带安全边界的行动层

Agent 的所有对外操作都收敛在这一层。核心是两部分：标准化的工具协议，以及刚性的安全沙箱。 工具调用的安全三原则：最小权限、网络隔离、资源限制。代码执行、系统操作必须在沙箱内运行，绝对不能让 Agent 直接操作核心业务库。

• 主流选型：MCP 协议（工具标准化）、E2B（代码沙箱首选）、Docker 自建沙箱
• 选型建议：仅调用内部 API 的场景，做好权限管控即可，无需沙箱；涉及代码执行、外部访问建议上沙箱。

L6 状态与记忆层：分层的用户数据管理

将记忆分层管理：工作记忆、短期记忆、长期记忆、情景记忆、语义记忆，不同层级采用不同的存储策略、过期策略、脱敏策略。 核心是在个性化体验与数据合规之间找平衡，该记的记，不该存的绝对不存。

• 主流选型：Mem0、Zep、自研数据库存储
• 选型建议：初期用关系库存会话记录即可，记忆分层需求明确后再上专业组件。

L7 评测与质量层：质量的自动化门禁

对应业务侧的评估工程，技术侧提供自动化评测能力，包括事实一致性、相关性、幻觉率、工具调用成功率等核心指标。 生产级部署的标准动作是：设置发布门禁，新版本核心指标不达标，禁止上线。

• 主流选型：RAGAS、DeepEval、LangSmith
• 选型建议：先落地核心指标人工评测，稳定后再做自动化门禁。

L8 可观测与运营层：全链路的运维底座

三大核心支柱：Tracing 全链路追踪、Metrics 指标监控、结构化日志。 对于 Agent 系统，可观测性不是运维需求，是核心调试手段。一次请求从输入到结果，经过了哪些模型、调用了哪些工具、每一步耗时多少、Token 消耗多少，必须全程可追溯。没有链路追踪的系统，线上问题几乎无法定位。

• 主流选型：LangFuse（开源首选）、LangSmith、OpenTelemetry 自研
• 选型建议：生产上线建议有基础链路追踪，这是排查问题的核心抓手。

最小可用埋点示例（核心三项必须打）

# 一次模型调用的标准埋点，覆盖核心排查字段 with langfuse.trace(name="reimburse_verify") as trace: # 1. 记录Prompt输入 trace.span(name="prompt_build", input=prompt_content) # 2. 记录模型调用与Token消耗 llm_span = trace.span(name="llm_call", model="gpt-4o-mini") result = llm.invoke(prompt_content) llm_span.end(output=result.content, usage=result.usage_metadata) # 3. 记录工具调用与返回结果 trace.span(name="tool_call", tool="amount_check", output=verify_result)

（二）横向四项治理能力

四项能力贯穿所有技术层级，是企业级系统的标配：

• 安全治理：全链路身份认证、数据防泄露、Prompt 注入防护、审计日志
• CI/CD 与发布治理：全资产版本化管理，灰度发布、快速回滚
• FinOps 成本治理：全链路成本计量，按场景、部门、用户精准归因
• 开发者体验：调试台、Trace 回放、评测看板，提升研发效率

五、架构映射与现实错位：理想很丰满，落地要务实

（一）核心架构映射表

十二项业务能力是视角的「职能清单」，九层 AI 基建是技术视角的「组件清单」。二者并非一一对应，而是业务职能通过多个技术组件的协同来落地。

表格

（二）现实落地的三大错位

上面的映射是理想架构下的对齐，但真实项目里永远是混乱的。三个最高发的错位，也是最容易卡项目的点，几乎每个落地项目都会遇到：

1. 业务语义与技术实现的错位：业务说的「预算」和系统里的字段不是一回事，这不是技术能解决的，必须拉业务方对齐，先做核心实体的语义约定，再做技术映射。
2. Harness 职责的边界错位：很多团队把业务规则写进编排层，最后变成大泥球。原则是：Harness 只管运行时管控，业务规则必须下沉到 Skill 或业务系统。
3. 流程与 Agent 的权责错位：试图用 Agent 管流程流转，最后审批规则混乱。Agent 只负责节点内的智能处理，流程定义必须交给 BPM 或流程引擎。

六、分阶段落地路径与生产自检清单

三阶段演进策略

企业级 Agent 落地不能一步到位，必须分阶段演进，每个阶段有明确的架构目标和决策原则。

第一阶段：验证期—— 价值验证，拒绝过度设计

• 核心目标：快速验证场景的业务价值，证明「AI 能解决这个问题」。
• 架构策略：直接使用商用大模型 API + 轻量向量库 + 简单链式编排，最快速度跑通核心链路。
• 避坑提醒：不要一上来就搞私有部署、搞复杂架构，先证明这件事值得做。

第二阶段：原型期—— 闭环跑通，夯实运行底座

• 核心目标：形成最小可用闭环，能在小范围试点稳定运行。
• 架构策略：补齐模型网关、图编排引擎、工具沙箱、基础可观测、基础权限体系。
• 避坑提醒：不要急于堆功能、扩场景，先把一条主链路跑稳，做到有兜底、可追溯、出问题能定位。

第三阶段：生产期（持续迭代）—— 治理补全，规模化复制

• 核心目标：全量上线，支持多场景横向复制。
• 架构策略：补全本体建模、业务流程对接、全链路可观测、发布治理、成本治理、多租户体系。
• 避坑提醒：不要跳过治理直接全量推广，数据安全、合规、权限的问题，一旦爆发就是严重事故。

生产上线自检清单

最后给大家一份可直接对照的自检清单，不用等项目暴雷再回头补。

七、落地实操：三个「脏活」难题的具体解法

聊完了整体路线，再聊点落地细节，回应几个最常见的现实疑问。这些都是项目推进到深水区一定会撞上的硬骨头，也是最能区分 Demo 和生产的地方。

1. Harness 层：长事务、异步回调与幂等设计

现实痛点：财务、审批类系统大多是异步回调，报销流程跨天甚至跨周，很容易出现重复执行、状态不一致、回调丢失的问题，这也是很多 Agent 一接业务系统就翻车的核心原因。

核心设计原则：以业务单据 ID 为全局幂等键，状态持久化优先，用补偿替代回滚。

• 幂等设计：每个节点执行前先校验幂等键状态，已执行则直接返回历史结果，不重复调用业务接口；节点执行成功后再更新状态，避免部分成功。
• 长事务处理：不追求分布式强一致，采用「本地状态 + 异步补偿」模式。财务接口调用失败不回滚前面的节点，记录异常后走人工兜底，后续手动补偿。
• 技术落地路径：
  • 轻量方案（LangGraph）：用 PostgresSaver 做 Checkpoint 持久化，每个节点手动加幂等校验，外部任务轮询回调状态。缺点是需要自行处理并发与异常恢复。
  • 成熟方案（Temporal）：原生基于事件溯源的持久化执行，Activity 级别自动幂等、自动重试，天然支持跨天长流程，信号机制可对接异步回调。缺点是有一定运维成本。

以下为幂等校验的核心模式示意，实际项目需根据具体存储引擎和并发策略调整。

def verify_amount_node(state): # 1. 以报销单ID为幂等键，先查执行状态 record = state_db.get(state["reimburse_id"], "verify_amount") if record and record["status"] == "success": return {"verify_result": record["result"]} # 2. 执行业务校验（Skill调用） result = skill_client.call("amount_check", state["invoice_info"]) # 3. 写入状态，标记已执行 state_db.set(state["reimburse_id"], "verify_amount", {"status": "success", "result": result}) return {"verify_result": result}

2. 存量系统：本体建模不用「强行拉通」，做语义映射层

现实痛点：不同部门、不同系统对「预算」「报销单」「客户」的口径完全不一样，强行统一会引发业务方抵触，项目直接卡死。

落地思路：先映射，后拉通，核心先行，逐步收敛参考 Palantir 本体落地的核心思路，不要上来就做全局大统一，分三步走：

1. 业务概念梳理：抛开系统表结构，先和业务方对齐「做这个场景，核心要用到哪几个业务概念」。比如报销场景，核心就是员工、报销单、发票、预算四个实体，先把这四个的业务定义说清楚，不纠结全量。
2. 数据源映射：给每个业务实体做字段映射表，把 OA、财务、预算系统里的对应字段，映射到统一的业务实体属性上。中间加一层语义适配层，不改造存量系统，业务口径变化只改映射层。
3. 逐步收敛口径：核心场景先跑通，后续随着项目推进，逐步推动非核心字段的口径统一。

一句话总结：不要试图改造业务，先做翻译官，让 Agent 能看懂不同系统的话。

3. 中小团队架构裁剪：抓核心项，避免过度设计

肯定有人会说，这套架构太重了，老板只给两周时间，根本做不完。 完全同意。全量落地是大厂中台的终态，绝大多数团队，抓住核心项就能覆盖大部分高频生产风险。裁剪原则是：必选项不能省，可选项后补，先跑通闭环再补治理。

• P0 必做（4 项）：Prompt 工程（边界定义）、Context 工程（基础 RAG）、Skill 工程（核心工具封装）、基础安全治理
• P1 生产必补（3 项）：Harness 基础调度（状态 + 重试）、基础可观测（链路追踪）、数据标准化
• P2 规模化再补（5 项）：本体建模、全流程对接、完整评测体系、成本治理、产品体验优化

轻量化技术栈推荐： 商用大模型 API + LangGraph + pgvector + 关系库存状态 + LangFuse 做链路追踪 这套组合足够支撑单场景试点，跑通核心闭环，后续再按需升级组件，不会出现架构推倒重来的问题。

写在最后

说到底，企业 Agent 的落地，拼到最后拼的不是模型能力，是系统工程能力。 模型是通用的，Prompt 是可抄的，真正的壁垒，在于是否能把业务拆解清楚、把架构设计合理、把工程体系做扎实。从 Demo 到生产，隔着的从来不是一个更好的模型，是一整套从业务到技术的体系化工程能力。

但也不要被这套完整体系吓住。所有复杂系统都是从简单原型长出来的，不是一开始就设计出来的。你可以从一个场景、四个核心工程开始，先跑通闭环，再沿着地图一步步补全。 不用强迫自己一次性落地所有模块，收藏起来，项目卡在哪一步，回来翻对应的章节就行。

当整个行业都在聊模型、聊 Agent 的时候，沉下心把工程底座打牢，才是真正的长期主义。