企业官网建设流程全解析

最近在帮一家做供应链管理的企业梳理内部 AI 工作流的时候，对方负责人问了我一个问题：我们单独跑一个智能体、做一个问答机器人，效果已经挺惊艳了，为什么一旦要它接进真实的业务流程，比如订单异常处理、售后工单审核，立刻就变得不可靠？

这个问题我几乎在每家客户那里都听到过。单个 Agent 在演示环境里表现得像模像样，一上生产环境就原形毕露：状态记不住、工具调错、中间结果没人复核、出了错也不知道去哪个环节排查。原因很简单：真实的企业流程从来不是“一段连续对话”，而是多个岗位、多个系统、多次交接组成的长链路。你要让 AI 真正跑起来，就不能只关注单个 Agent 强不强，而是要关心一群 Agent 在一起协作时，背后的技术架构能不能撑住。这就是“从 Agent 到 Agentic Collaboration”这条路上，最容易被忽视、也最决定成败的地方。

这篇文章我想结合这段时间的落地经验，把企业 AI 工作流背后的架构分层、关键实现、踩坑记录完整拆一遍。不管你是技术负责人、架构师，还是正在把 AI 接进业务的应用开发者，应该都能拿走一些可以直接用的东西。

1. 先从“一串工具”到“一支队伍”：Agent 协作的问题本质

很多团队对 Agent 协作的第一反应是：多接几个大模型服务，让它们互相调用不就行了？理论上是这样，但实际跑起来完全不是一回事。

1.1 单体 Agent 为什么撑不起企业流程

单体 Agent 的优势很明显：上下文集中、工具调用灵活、部署简单。你给它一个复杂的任务，它可以自己规划步骤，调一堆外部 API，最后给你一个结果。这套模式适合处理“单次交互型”场景，比如合同风险初筛、政策问答、技术咨询。它的能力上限在于，所有状态都堆积在同一个上下文窗口里，一旦流程拉长，前边的判断错误会把后边的决策全部带偏。

举一个真实的订单异常处理场景：用户发起售后工单，系统需要先查订单状态、再查库存、再查物流、然后判断是退款还是补发、最后调用财务或仓储接口。单体 Agent 可以串行完成这些步骤，但它把所有中间结果都揉在一个上下文里，自己在“脑子里”维护状态。一旦中间有一次工具返回格式异常，或者某个步骤需要回头修正，它很容易把自己绕晕。而且整个过程没有复核环节，错了一路错到底，等用户投诉、财务对账才发现，损失已经造成。

说到底，企业流程有两个单体 Agent 天然搞不定的特征：其一是多步骤、多分支，每一步的失败都可能触发补偿逻辑；其二是需要多人协作式的校验，关键决策不能只靠模型拍板。一个人再能干，也替代不了一个有着明确分工、交接和复核机制的团队。

1.2 协作不只是“让两个 Agent 聊天”

我见过不少团队把两个 Agent 接在一起对话，就声称实现了“多智能体协作”。坦白说，这基本是伪协作。你让一个 Agent 把任务丢给另一个，对方答不上来又丢回来，来回几轮上下文膨胀了好几倍，钱烧完了，活没干成。

真正有意义的 Agentic Collaboration，本质是“组织分工”，不是“多人聊天”。企业内部一个工作小组怎么运转？不同角色各有职责范围，每个角色只关心自己那部分工作，做完产出一个标准化的交付物，交给下一个环节。下一个环节不需要知道你内部思考了多久、调用了哪些工具，只需要接收一个合格输入，再产出合格输出。Agent 协作也应该照这个逻辑来设计。

用订单异常处理来说，最合理的分工不是让一个 Agent 从头包到尾，而是分开成信息采集、根因判断、行动决策、执行操作、结果审计几个角色。“信息采集 Agent”只负责查数据，“决策 Agent”只看经过整理的数据出策略，“执行 Agent”负责调接口但是自己不做判断，“审计 Agent”负责盯结果。每个 Agent 的上下文是独立且精简的，消息通过明确结构传递，出问题可以按交接记录回放。这样才是企业级协作。

1.3 企业落地最需要的能力：可控、可管、可复盘

我为什么一直强调“企业级”三个字？因为个人开发者做 Demo，不需要对结果负责；企业不行。企业流程涉及钱、合同、用户数据，系统的每一次决策都得说得清楚：为什么这样判断、调用过哪些系统、花了多少成本、有没有超过阈值需要人工介入。这要求架构不仅是“能把事办成”，更得是“可控、可管、可复盘”。

可控，指的是关键路径上的行为是确定的：该查库存一定查库存，该转人工一定转人工，不能每次运行跑出不同的路线。可管，指的是每个 Agent 的角色边界清晰，权限可控，工具调用有审批。可复盘，指的是每次执行都有完整链路记录，出了问题能往回追溯。想满足这三点，靠“一个巨大 Prompt + 全功能 Agent”是做不出来的，必须回到分层架构上去解决问题。

2. 企业 AI 工作流的架构分层：把智能关进“笼子”里

我第一次给团队讲分层架构的时候，有人问：把逻辑写进 Prompt 不也是架构吗？短平快确实可以，但它扛不住生产环境。我把一个企业级 AI 工作流拆成三层来看：基础设施层、编排层、应用层。核心思想就一句话：稳定性靠架构，智能靠模型，确定性靠代码。

2.1 为什么不能把一切逻辑都写进 Prompt

很多早期项目长这样：一个上万字的系统 Prompt，里面对话风格、业务流程、工具使用、输出格式全写了。Demo 阶段跑得挺漂亮，但上线后就是灾难：

第一，结果不可测。大模型对 Prompt 的理解是概率性的，稍微措辞调整，输出就变了，流程会走出不同的分支。第二，权限难控制。如果一个 Agent 什么工具都能调，只要 Prompt 里有一句话引导错误，它就可能调用不该调的接口。第三，成本难优化。全部消息都塞在一个上下文里，token 消耗随对话轮次线性上涨。第四，问题难定位。所有行为纠缠在一个模型调用里，出了问题你不知道是 Prompt 的问题、还是工具返回的问题、还是上下文被污染的问题。

我在实际项目里的原则很简单：凡是可以用代码写清楚的逻辑，比如状态流转、权限校验、超时重试、金额上限判断，绝对不丢给大模型决策。大模型只做它擅长的事：语义理解、信息抽取、方案生成、自然语言润色。流程骨架是确定的，Agent 只是骨架节点上的“智能执行器”。

2.2 基础设施层：模型网关、向量库与工具注册中心

这一层是整个架构的地基，很多团队忽略它，直接写业务逻辑，后面才来补课。

模型网关解决的是“接入混乱”问题。企业内部往往同时测试多个模型服务，不同产品线的需求也不一样：有的要便宜，有的要回复快，有的要复杂推理强。没有统一网关，每次换模型要改代码，成本记录也散在各处。我做模型网关的时候，至少会封装这几个能力：统一调用接口、路由策略（按任务类型分发到不同模型）、限流与重试、token 成本统计。网关层把大模型当成可替换的组件，业务代码不直接依赖具体供应商。

向量库在企业 AI 工作流里扮演“长期记忆”的角色，用来存放企业私有知识和历史沉淀：比如政策文档、历史工单、过去的协作记录。它的作用不是替代数据库，而是提供一种语义检索能力。多 Agent 系统里，向量库同时也是共享记忆的落点，后续上下文管理那一节我会重点展开。

工具注册中心是我最想强调的部分。很多团队把工具描述写在 Prompt 里，让大模型自己发现并用 JSON 去调用。Demo 可以，生产不行。我建议把企业系统的每个能力封装成标准工具，注册到中心，每个工具包含：名称、用途、输入 Schema、输出 Schema、调用地址、权限范围、超时时间、频控限制。注册中心同时也暴露给编排层做路由判断，而不是每次都靠模型自己发挥。

2.3 编排层：确定性状态机与动态路由的取舍

编排层处理的是“下一步干什么”。业界有两种风格：确定性工作流和智能动态路由。

确定性工作流就是预先画好流程图：第一步做什么、条件分支怎么走、异常怎么处理。适合稳定且可穷举的流程，比如工单分类、订单查询、退款审核。优点是可控、可调试、可审计，缺点是不够灵活，业务流程一变，代码就要跟着改，而且对没预见过的场景毫无办法。

智能动态路由则是让 Agent 自己决定下一步调用什么工具、交给哪个 Agent。这种方式灵活，能处理开放性问题，比如“帮我分析这个季度的销售异动原因”，但不可控：Agent 可能走出一条谁也想不到的路径，也可能陷入死循环，成本还波动很大。

我在企业落地时强烈推荐“确定性为主、动态决策为辅”的混合模式。主流程用状态机固定住，每个状态内部保留模型的决策空间。类比就是流水线固定不变，但工位上的工人可以自己选择用什么工具把活干完。以退款流程为例：是先审计还是先执行，这是流程规定，不能用模型来决定；但“该客户的退款理由是否合理”“风险等级高不高”，这种判断可以交给模型。固定的是框架，智能的是决策节点。

2.4 应用层：任务分解、上下文传播与结果聚合

应用层是和业务最贴近的一层，直接接收用户请求，负责拆解任务、分配 Agent、收集结果。

任务分解的质量决定了协作的成败。有两个核心点：一是要识别依赖关系，二是要控制拆分粒度。拿“客户投诉物流慢并要求补偿”这个请求来说，你不能简单切成“查物流”和“给补偿”两个并行任务，因为“是否补偿、补多少”依赖查物流的结果。拆任务时必须保留依赖拓扑，有的要串行、有的可以并行。拆分粒度也不要太细，一个 Agent 能完成的事情硬拆成三步，只会增加通信和交接成本，还会放大出错概率。

上下文传播是应用层另一个关键职责。不是每个 Agent 都需要看全量对话历史。我通常设计一个上下文构建器，每个 Agent 执行前临时组装它需要的背景信息：用户原始输入的部分片段、前置 Agent 输出的结构化数据、向量库检索到的相关知识。只投喂必要信息，既省 token，也让 Agent 不容易被无关信息干扰。结果聚合则是把各个 Agent 的产出合并成用户能看懂的最终答复，同时保留结构化中间结果，方便后续审计和二次处理。

3. 多 Agent 协作的几个关键技术细节

架构分层定下来之后，真正决定项目能不能稳定跑的是几个细节。这些细节在原理文章里经常被一笔带过，但落地时每一个都能让你折腾一周。

3.1 通信协议：先定义好消息信封，再谈协作

Agent 之间传递的消息不能是“一段自然语言聊天记录”，必须是结构化消息。我的做法是统一信封格式，至少包含以下字段：

{ "task_id": "T20240501001", "trace_id": "TR_8fd2k3", "message_id": "M_001", "from_agent": "analysis", "to_agent": "execution", "message_type": "decision_result", "priority": "normal", "deadline": "2024-05-01T10:00:00Z", "payload": { "action": "refund", "amount": 199.0, "reason": "item_damaged", "order_id": "ORD123456" }, "schema_version": "1.0" }

task_id 是业务实例 ID，属于哪个工单，一目了然。trace_id 用于链路追踪，一次完整协作里所有 Agent 调用共享同一个 trace_id。from/to 明确消息方向，message_type 约定语义类型。payload 是具体业务数据，不夹杂任何自然语言。

这套消息结构有三个直接好处：支持可靠重试，执行 Agent 收到消息后即使中途挂了，重放消息还能恢复现场；支持链路追踪，每个消息在哪个环节耗时多少都能记录；支持权限控制，目标 Agent 只需要校验 message_type，不用去解析自然语言，过滤非预期消息。我在带团队时要求所有 Agent 之间的通信都必须走这个信封，一旦有人图省事直接传字符串，后面排障就会非常痛苦。

3.2 上下文管理：别把所有对话历史到处塞

多 Agent 系统里最常见的技术债，是把所有历史记录塞给每个 Agent 做“记忆增强”，结果上下文越滚越大，token 成本直线上升，模型注意力被无关信息稀释，输出质量反而下降。

解决思路是“上下文按需投递”。每个 Agent 只维护自己的最小上下文，并且在入口处用一个 context builder 来组装。我通常会写一个这样的逻辑：

def build_minimal_context(agent_role, task_meta, historical_events, knowledge_base_client): context = [] # 只附加与当前任务直接相关的背景信息 if agent_role == "decision": # 决策 Agent 只需要订单摘要、物流状态、风险提示，不需要原始聊天记录 context.append(f"Order summary: {task_meta['order_summary']}") context.append(f"Logistics status: {task_meta['logistics_status']}") if task_meta["risk_hit"]: context.append(f"Risk alert: {task_meta['risk_reason']}") elif agent_role == "execution": # 执行 Agent 只需要决策结论，不需要知道为什么这么决策 context.append(f"Execution instruction: {task_meta['decision']}") # 按需检索知识库，不要全量灌给模型 if task_meta.get("need_knowledge"): hit_chunks = knowledge_base_client.search(task_meta["query"], top_k=3) context.extend([f"[Knowledge] {c}" for c in hit_chunks]) return "\n".join(context)

这里的核心思想是：上下文不是“越多越好”，而是“够用就好”。决策 Agent 需要知道采购原因和成本数据，执行 Agent 只需要知道执行动作和参数。如果没有这种隔离，一个 Agent 的错误输出很容易污染另一个 Agent 的判断。

共享记忆的处理也值得单独说。我把跨 Agent 的共享记忆放到外部存储里，比如向量库存放语义化的历史记录，KV 存储存放短期业务状态。每个 Agent 读取记忆的时候都有权限范围和维度限制，不是谁都能访问全部记忆。这样既保证信息共享，又避免“群体幻觉”：某个 Agent 产出了一个错误中间结论，其他 Agent 拿不到或者能识别出来，不会盲目跟着走。

3.3 可观测性：从“黑盒”到可追踪

多 Agent 系统的排障难度远大于单体应用。单体应用一个栈堆打出来就定位了，多 Agent 是一条链路，问题可能发生在任意节点，而且每个节点还有模型调用，输出是概率性的，同一段输入两次运行结果都可能不一样。

所以可观测性在设计阶段就要考虑。我在项目里至少给每次 Agent 调用记录五类信息：输入摘要、输出摘要、使用的工具与参数、token 消耗与耗时、置信度评分。记住这五类数据，按 trace_id 汇总成一个完整链路画出来，才能回答“系统今天这笔订单为什么处理错了”。

落到实现上，我会在消息信封里带 trace_id，并在公共调用入口埋点。简单点可以直接打结构化日志，再装一个轻量日志面板；规模大了再接链路追踪中间件。生产环境里还有一个很实用的策略：让每个 Agent 返回结构化的“处理摘要”，而不是一段自然语言总结，比如“已确认订单存在、库存充足、物流延迟2天、建议补发”。这样排障时可以直接在日志面板里扫这些字段，快速判断是信息采集错了、决策错了还是执行错了。

3.4 幂等与容错：生产环境的底线

这一条很朴素，但是绝大多数从 Demo 走向生产的项目都栽在这里：工具调用没有幂等设计。Agent 调用退款接口时网络超时了，它会重试，如果每次都生成同一个 request_id，服务端还能去重；如果没有 request_id，同一次业务动作可能被执行两次，客户收到两笔退款，事故级别的错误。

我的规则是：所有会对外部系统产生副作用的工具调用，必须携带幂等键。在前面的消息信封里，message_id 就是天然的幂等键。执行 Agent 调用工具时把这个 message_id 传过去，外部系统记录并识别重复调用。

容错策略也不能靠运气。要在编排层设置明确的兜底动作：重试两次还是三次、每次退避多久、失败之后是转人工还是降级到另一条路径。我的建议是重要的资金类操作宁可慢一点，也要配置“失败转人工”；信息类查询可以多做几次自动重试。系统里要有全局超时和最大协作轮次，防止 Agent 之间无限循环把预算打爆。

4. 一个客服工单系统的完整落地拆解

前面讲了那么多架构和原理，接下来我用一个完全虚构但高度还原的“客服工单自动处理”场景，把落地过程完整串一遍。用到的企业名称都是代称，代码思路可以直接参考。

4.1 场景需求与 Agent 划分

某电商企业的客服部门每天接到大量售后工单，人工处理成本高、响应慢。需求是：用户提交工单后，系统自动完成问题分类、信息核验、方案决策、自动执行或转人工，并生成处理摘要。我按职责边界把任务划分为五个 Agent：

这五个角色不是随意划分的。它们对应了企业客服后台真实岗位：录入员、查单员、主管、操作员、质检员。每个 Agent 都只做一类事，输出有明确格式，边界清晰，即使某一个 Agent 升级换代，其他 Agent 完全不受影响。

4.2 数据流与状态机设计

这个系统的主流程可以用一个状态机描述。工单状态依次经过：待解析、核验中、待决策、待执行、待审计、已完成。如果任一环节出现低置信度或超时，状态跳转到待人工复核。分支其实只有两条：自动处理与转人工。从“待决策”到“待执行”需要满足前置条件：决策置信度高于 0.85，且金额在 500 元以内。否则转人工。

数据流遵循“上一环节的输出就是下一环节的输入”原则。入站解析 Agent 输出一个 JSON 对象，包含 intent、order_id、product、issue_type、user_description；信息核验 Agent 拿到这个 JSON 仓库查数据，返回 inventory_status、logistics_status、payment_status。决策 Agent 不接触原始用户评论，只看核验报告，避免被无关情绪化语言干扰。这样就实现了信息隔离，每一层拿到的都是“经过整理的事实”。

这个阶段我特别提醒：状态机一定要把“转人工”设计成一个明确状态，而不是异常分支。因为转人工不是失败，是系统主动做的风险规避。人工处理完以后，还需要一条路径把结果回流到系统，更新工单状态。如果这个细节没设计，人工处理完的信息在系统里就断了，后边审计和数据分析都会缺一块。

4.3 核心代码与配置示例

状态机我这里用一个简化的状态定义来示意，重点看每个节点如何调用对应 Agent：

# 简化版状态流转定义 state_machine = { "PENDING_PARSE": { "action": "invoke_agent", "agent": "parse", "next_on_success": "VERIFYING", "next_on_error": "HUMAN_REVIEW" }, "VERIFYING": { "action": "invoke_agent", "agent": "verifier", "next_on_success": "DECIDING", "next_on_error": "HUMAN_REVIEW", "max_retry": 2 }, "DECIDING": { "action": "invoke_agent", "agent": "decision", "next_on_success": "EXECUTING", "next_on_low_confidence": "HUMAN_REVIEW", "next_on_error": "HUMAN_REVIEW", "confidence_threshold": 0.85 }, "EXECUTING": { "action": "invoke_agent", "agent": "executor", "next_on_success": "AUDITING", "next_on_error": "HUMAN_REVIEW", "idempotent_key": "message_id", "max_retry": 1 }, "AUDITING": { "action": "invoke_agent", "agent": "auditor", "next_on_success": "COMPLETED", "next_on_error": "HUMAN_REVIEW" } }

决策 Agent 的 Prompt 我会刻意写得收敛，不让它自由发挥太多。它只有一个核心任务：根据传入的核验报告，输出以下结构的 JSON：action、reason、amount、confidence。同时给它一个风险规则清单，比如“高价值订单必须转人工”“用户历史投诉超过3次的标记风险”。这些规则里相当一部分用代码在编排层做前置检查，剩下语义判断的部分才交给模型。

执行 Agent 的代码里有一个关键点，所有工具调用必须带幂等键：

def execute_tool(tool_name, payload, message_id, executor_client): # 将 message_id 作为幂等键传给外部系统 result = executor_client.call( tool=tool_name, params={**payload, "request_id": message_id} ) return result

外部系统在接口层用 request_id 做幂等判断，如果之前已经处理过同一个请求，直接返回历史结果，不重复执行。这一行代码能挡掉生产环境里最危险的那一类事故。

4.4 成本控制和效果调优

系统上线之后，我先做了一轮成本观察。最初所有环节都调用同一种高级推理模型，一个工单全链路大概消耗几万 token，成本很高。后来我把每个 Agent 的任务难度做了区分：入站解析和信息核验这种模式化任务，切换到低成本快速模型；决策和审计保留高级模型。只做这一个分流，整体成本大约降了一半。

从延迟角度看，并行化收益明显。信息核验本来要查订单、物流、库存三个地方，如果按顺序查要串行 3 次接口调用，延迟累加。我把它们改成并发查询，等所有子结果返回后再组装核验报告，整体耗时降了大约三分之一。但要注意：只有相互独立的信息查询才能这样并行，有依赖关系的步骤绝不能为了省时间盲目并发。

调优过程中另一个重要指标是“自动执行率”。一开始系统非常保守，动不动就转人工，操作员都在吐槽加了套新系统活没变少。后来我不是简单调低置信度阈值，而是去看决策 Agent 被拒绝的案例，发现很多是因为数据字段缺失导致判断不了。补上缺失字段后，自动执行率明显提升。置信度阈值从 0.85 往下调，每调一档都要对照误处理率，成本节约和风险之间要做平衡。

5. 实战中遇到的典型问题与排查手册

这部分是我真正想分享的干货。前面是方法，下面全是坑。每一个都是真金白银换出来的经验。

5.1 Agent 互相“踢皮球”与死循环

现象是系统日志里出现同一对 Agent 反复互发消息，A 说该 B 处理，B 说该 A 处理，直到触发最大轮次限制才停，既浪费时间又烧钱。

根因：Prompt 里的职责边界描述不够刚性。模型在模糊语境下会把任务推给“看起来更专业”的其他 Agent，或者说一句“这不是我的职责范围”就试图结束任务。

对策有三层：第一层，在编排层设置最大协作轮数和全局超时，这是保底，必须有。第二层，在 Prompt 里写硬约束，明确“你收到的任务已经在编排层确认属于你，你必须产出结果，不得移交其他 Agent，除非满足特定条件”。第三层，也是最有效的：尽量让 Agent 之间不要直接对话，所有传话都经过编排层。A 想传消息给 B，先把消息发给编排层，编排层按预设路由决定是否转发。这样职责边界就从 Prompt 约束变成了代码约束，可靠性直接上一个台阶。

5.2 上下文爆炸与 Token 成本失控

有一次我发现一个工单的链路追踪里，最后一个 Agent 的输入上下文里居然包含了前面所有的对话历史，连用户最早的原始留言都完整躺在里面。这个工单本身处理逻辑没问题，但 token 消耗是正常情况的 5 倍，而且随着协作轮次增加还在涨。

这种情况基本都是因为共享变量的滥用：为了图省事，把一份“全局上下文”传给了所有 Agent。模型效果不会因为信息全而变好，反而会因为被无关信息干扰而变差。

解决方法是严格执行“按需投递”。我后来给上下文构建器加了一个白名单机制：每个 Agent 声明自己需要哪些字段，构建器只允许透传白名单内的数据。同时引入摘要机制，对于长流程，不再存全量历史，而是用一个“阶段性摘要”替代中间过程。比如决策 Agent 不再关心信息核验 Agent 内部查了几个表，只需要接收一条精炼的核验结论。这个机制上线后，整体成本明显回落，准确率还稳中有升。

5.3 幻觉被放大：如何建立校验和复核机制

多 Agent 系统有个隐蔽风险：单一 Agent 的幻觉会在协作链路上被放大，后续 Agent 把它当成既定事实继续推导。比如决策 Agent 在核验报告里“脑补”出一个仓库缺货的判断，执行 Agent 就真的去生成补发指令。等到审计 Agent 发现不对，流程已经走到一半，不得不回滚。

这种问题不能靠“提示模型别幻觉”来解决，要建立程序化屏障。三个做法叠加：第一，关键节点用结构化输出约束，靠 JSON Schema 强制模型输出固定字段和合法取值，从格式上过滤掉了大部分胡说八道。第二，建立跨 Agent 交叉验证，决策结论必须过一遍审计 Agent，两者结论一致才算通过。第三，引入外部事实校验，比如决策 Agent 说“库存不足”，编排层可以顺手调一次库存查询接口做实际比对，用数据库事实纠正模型幻觉。这三层叠加之后，系统整体可信度才谈得上企业级。

5.4 排查工具与调试流程

多 Agent 系统出问题时，第一件事不是看 Prompt，而是先拉链路。我会先按 trace_id 把一次完整处理的日志全捞出来，按照消息信封里的 from_agent、to_agent 还原协作路径，看它实际上走出了哪条路，和设计的状态机路径比对，偏差点就是问题所在。

如果是信息采集环节出错，很好判断，看核验报告字段值对不对就行。如果是决策环节不合理，对比决策 Agent 的 Prompt 和当时输入的行向量，看是不是上下文少传了关键字段。如果模型老是输出不合法 JSON，优先检查输出 Schema 定义，以及是否缺少“必须返回合法 JSON，不要解释”的约束。如果偶尔超时，去看是外部系统慢还是模型响应慢，然后针对性重试策略。

调试流程我总结成一句口诀：先看链路对不对，再看数据准不准，最后才调模型和提示词。顺序反了，只能闻到烟味，找不到火源。

写到这里，我发现这类项目做得越多，越发觉得 Agent 本身没那么神秘，难点一直在工程组织上。把一个复杂流程拆成职责清晰的小模块，把通信、状态、容错、审计这些基础设计做好，比追求单个模型的“聪明程度”重要得多。我现在接新的落地项目，第一周基本不碰 Prompt，全部时间花在梳理流程边界和消息协议上。这块地基打稳了，后面接什么模型都能跑得顺畅。