企业官网建设流程全解析

我印象里第一次认真琢磨 Loop Engineering，是在一个多智能体项目把团队搞得快崩溃的时候。当时系统里挂了十几个 Agent，每个拿出来单挑都很聪明，写代码的能写代码，做 review 的也能正经挑毛病，可一旦把它们全串起来跑，整个协作过程就像一家管理混乱的皮包公司：任务派发靠“口头传话”，交接成果靠“我觉得”，出了问题没人认领，上下文在传递中被反复加油添醋，最后产出的质量还不如我把所有事塞给一个大模型。那段时间我几乎每天拿着 Trace 日志在找“到底是谁把需求理解歪了”。

后来我们停下来重新设计，查了大量 Agent 协作框架的资料，参考了几个不同行业的落地案例，才慢慢整理出一套方法论。这套东西现在业内给它起了个名字，叫Loop Engineering——不是指某一个框架、不是 LangGraph 也不是 AutoGen，而是把多智能体协作里所有“反馈回路”工程化的一整套设计思路。这篇我按自己的理解，把 Loop Engineering 的循环层次、协作架构的骨架、生产环境下踩过的隐性坑，以及我自己沉淀下来的一套最佳实践完整拆开来讲。适合正在搭多智能体系统、被协作复杂性折磨的研发、架构师，也适合想搞懂这类系统到底难在哪的产品和技术负责人。

1. Loop Engineering 谈的“循环”，到底是谁在循环

很多技术文章一上来就讲架构、讲拓扑，但其实大多数人搞不清 Loop Engineering 里的Loop 到底指的是什么。不是说这是个循环神经网络，也不是说程序里写个 while 循环就叫 Loop Engineering。我自己的理解是，它至少包含三个层面，三个层面都得闭合，这套系统才是工程上可用的。

1.1 第一层循环：单个 Agent 内部的知行闭环

很多 Agent 框架里都有“Agentic Loop”或者“Agent Reasoning Loop”的说法，翻译过来就是让模型反复迭代：感知当前状态 → 规划下一步动作 → 执行工具调用 → 观察结果 → 再修正计划。比如一个写代码的 Agent，收到需求后不是一口气把代码全生成完，而是先写一小段、跑一下测试、看到报错、修再跑，循环几轮直到通过。

这一层循环是 Loop Engineering 的微观基础。很多人误以为 Agent 就是“把 Prompt 写得足够详细然后调用一次模型”，但真正稳定可用的单 Agent 必须自带这个闭环。没有内循环的 Agent，本质上就是个带工具的 LLM，谈不上“智能体”。

我在工程上会要求每个 Agent 的循环里强制记录四个要素：Plan、Action、Observation、Result。这四样东西既是对模型推理路径的约束，也是后面整个系统可观测的前提。没有这个内闭环，你后面无论做多少 Agent 之间的架构设计，都会因为没有过程数据而无从排查。

1.2 第二层循环：智能体之间的信息回流

多智能体的协作之所以比单 Agent 复杂，不只是多了几个“角色”，而是多了跨 Agent 的反馈回路。打个比方：单 Agent 像一个人闭门造车，多 Agent 像一条流水线。流水线的问题在于，工序 A 干完交给 B，B 干完交给 C，结果最终 C 发现最开始 A 的理解就错了。最原始的多 Agent 协作是单向的：A→B→C，信息只往下游流，没有回流通道，于是错误一路到底。

Loop Engineering 在这里的关键操作是，把“反馈”从一种事后补救变成结构上的必然路径。典型例子是测试驱动型的多 Agent 协作：开发 Agent 写完代码，测试 Agent 跑用例并把失败详情返回给开发 Agent，开发 Agent 根据失败信息修正后重新提交。这个“返工”就是回流。再比如数据标注场景，标注 Agent 生产一批结果，质检 Agent 抽检后把不合格样本和标注标准偏差反馈给标注 Agent，促使它调整 Prompt 或 few-shot 示例。

所以，判断一个协作架构有没有“工程化”意识，就看它的信息流是不是闭环的。闭环的信息流意味着下游能向上游反馈错误、上游能根据反馈调整行为、整体系统在环境变化时能自校准。而所谓“协作架构的内幕”，本质上就是设计这些回流通道在什么位置存在、以什么形式传递。

这里有个很常见的反面案例：很多人搭多 Agent 系统时，每个 Agent 之间都是“自然语言传话”——上游输出一段文字，下游直接拿来当输入。看起来灵活，但下游根本没有机制告诉上游“你这段话里有三个地方我理解不了”。自然语言的信息密度大，失真率也高，靠模型自己猜来维护协作质量，本质上是在赌博。

1.3 第三层循环：人类与系统之间的外闭环

最后这一层往往被技术团队忽略，却是生产系统里最重要的一层：人仍然要留在循环里，但不能事无巨细地掺和。Loop Engineering 不是追求全自动化，而是把自动化边界划清楚，把“哪些环节必须人去审”也当成工程结构的一部分来设计。

比如在代码生成系统里，如果每次提交都让工程师去逐行 review，那是流程死板；但如果完全不让工程师看，Agent 自己修自己的 bug，就很容易出现“修补了一个问题引入三个新问题”的场面。合理的做法是：Agent 在自主循环里做修改，但变更要经过一个独立的评审 Agent 过滤，评审不通过的自动打回，只有到达置信度阈值后的变更才提交给人做终审。

这一层的本质是：人不是“兜底的工具”，人是外循环的决策环节。系统必须给人在足够的信息下做决策的能力——这就牵涉到后面要讲的可观测性。一个不能回放 Agent 每一步动作的系统，人是没法有效参与外循环的。

2. 协作架构的底层骨架：编排模式与通信协议怎么选

聊完循环的层次，就该说“协作架构怎么长出来”了。一个具体问题：多智能体之间的组织结构，到底选树状、流水线还是网状？我自己试过几乎所有主流模式，结论是——没有最先进的模式，只有匹配场景的模式。

2.1 四种主流拓扑对比：不需要发明新花样，但要选对

我在设计系统时经常拿四种拓扑做基准：Sequential（流水线）、Hierarchical（主管 + 执行者）、Blackboard（黑板 / 共享内存）、Network（网状协商）。它们各有各的适用场景。

从我个人的经验来说，生产系统里首选 Hierarchical，因为它把路由收敛到单点，出问题时的排查方向很明确。很多人一上来就搞 Network 全互联，觉得这才够“自主”，结果协调成本爆炸，连一次完整跑通都很难。

2.2 通信协议：别让 Agent 用“人话”互相传话

多智能体系统最容易犯的错误，是把 Agent 之间的通信当成“聊天”。我在生产环境里强烈建议：Agent 之间不要直接交换自由文本，要交换结构化消息。什么意思呢？每个 Agent 的输出，不只是“一段回答”，而是一个带元信息的 Schema，至少包含：消息类型、发送者、接收者、任务 ID、追踪 ID、时间戳、正文内容、以及显式的质量声明。

举个实际例子。我们系统里所有消息都走类似这样的 JSON 结构：

{ "message_type": "task_assignment", "trace_id": "trace-7f3a9c2e", "task_id": "T-4211", "from": "orchestrator", "to": "code_reviewer", "payload": { "artifact_ref": "artifact://T-4211/codebase_v3.diff", "review_criteria": ["compile", "conventions", "security"], "confidence_threshold": 0.8, "deadline": "2025-06-14T12:00:00Z" } }

为什么非要用结构化消息？因为 Agent 的自主性恰恰建立在高约束的协议之上。如果每个 Agent 都自由发挥，上游写一段散文，下游还得自己解析重点，那么解析错误就成了最大的不可控因素。而结构化协议让每个 Agent 的输入输出边界都变得稳定，这也让后面整个系统的可观测和评测变得量级化地简单。这个坑我踩得很痛——早期版本里，两个 Agent 靠自然语言讨论需求，结果它们“达成一致”的理解在人类看来完全是另一个需求。

2.3 状态同步：别把共享数据库当黑板

多 Agent 协作绕不开一个问题：“大家脑子里的当前状态一致吗？”我的经验是：不要直接给多个 Agent 共享同一个数据库表或某个全局变量，谁都能写，就谁都会乱写。黑板上谁都能留言，最后一定被涂得没法看。

更稳的方案是事件日志 + 物化视图：所有 Agent 的写入行为都表现为追加事件，系统按顺序重放事件，生成各个 Agent 看到的视图。这样任何一个 Agent 的行为都可以追溯——“它看到了什么、在哪个事件之后做的决定、基于哪份数据”。用工程上的话讲就是 Event Sourcing。

比如我们做内容生成系统时，编辑 Agent、润色 Agent、插图 Agent 都维护自己的视图，但底层只共享一条事件流：谁在什么时候提交了什么版本、谁批注了什么。进度条不是靠定时去查当前状态，而是靠重放事件算出来的。这样哪怕某个 Agent 中途崩溃重启，也能从事件流重建状态。没有这个设计，你会在排查问题时发现根本不知道某个 Agent 为什么做出某个决策。

2.4 编排器不是万能的，路由判断要简单粗暴

Hierarchical 结构里，主管 Agent（Orchestrator）的心智负担很重：它要决定“这个任务该派给谁”。很多实现问题恰恰出在这个环节——想让主管 Agent 全面理解任务再智能路由，结果它理解错了，整个系统跟着跑偏。

我自己的实践经验是：主管的路由决策尽量做成简单、确定性的判断，甚至用规则优先，模型判断兜底。比如先做关键词/类型分类，落在某几类就按固定模板派单，分类不明确的再交给模型判断。主管的职责是“派单 和 回收结果，而不是深度理解每个子任务”。以下这段伪代码就是我们一个真实项目的路由逻辑骨架：

def route(ctx): task = ctx["latest_task"] kind = classify_task(task) # 返回 codegen / review / integrate / human if kind == "codegen": return run_agent("coder", ctx) elif kind == "review": return run_agent("reviewer", ctx) elif kind == "integrate": return run_agent("integrator", ctx) else: return escalate_to_human(ctx) # 不要硬编，交给人的外循环

这个例子的核心思想是：路由如果做成了概率事件，整个系统就不稳定。在 Agent 编排层，我们追求的是“特定输入一定落到特定路径”，而不是让模型大模型临场发挥去猜该找谁。

3. 生产环境下才会撞见的隐性故障与排查链路

很多多智能体框架的 Demo 都跑得很顺，但你一旦把它接进生产、让真实数据流通起来，就会撞见一堆“Demo 里不存在”的麻烦。这一节专门聊聊那些在架构图上完全看不出来的隐性故障。

3.1 沉默失败（Silent Failure）：它没报错，但它错了

多 Agent 系统区别于传统微服务系统的一个巨大威胁，是沉默失败。传统服务如果挂了，监控会报警；但一个 Agent 如果“做出了错误的判断”，它不会抛异常，它会正常返回一个结果——一个看似合理、实则错误的结果。

举个例子。我们系统里有个审核 Agent，负责判断上游生成的代码是否存在潜在风险。某次上游交了一个任务，审核 Agent 因为上下文里缺失一段关键信息，返回了approved: true，但置信度只有 0.3。下游的生成 Agent 看到 approved 就直接继续跑了，最后合入主分支的代码带着一个已知缺陷。整个过程没有任何一行错误日志，因为每个 Agent 都在“正常地”执行自己的任务。

这个问题的可怕之处在于：多 Agent 系统的错误真正常走“异常路径”，而走“正常返回的谎言”。所以我们在设计上订了一条铁律：每个 Agent 的返回必须带上对自身产出质量的显式评估字段（比如confidence和self_review_result），下游接到低置信度结果时默认执行“打回重做”而不是“继续往下走”。这相当于给 Agent 之间的协作加上了一个“置信度安检门”。

3.2 错误级联：一个 Agent 的理解偏差，被下游放大成灾难

单 Agent 的错误影响范围是自己地界，多 Agent 的错误是会传染的。一个典型的级联链路是这样的：

1. 规划 Agent 把原始需求理解偏了，补充了一个并不存在的隐藏条件；
2. 它把这个条件写在任务描述里传给生成 Agent；
3. 生成 Agent 很听话，把偏了的条件实现了；
4. 评审 Agent 核对时，发现代码和原始需求能对上，只是多了一个多余行为，于是以“更好实现”的名义通过评审；
5. 最终交付物在人类用户眼中“就是不对”：
6. 你回查整个管线，发现所有人都在自己的局部视角里做出了“正确”决定。

这个场景我称之为“二传手效应”：信息每经过一个 Agent，都会被重新解读和润色；解读次数越多，语义偏移越大。就像传话游戏，说三句话之后原意已经面目全非。机械执行的步骤不会放大错误，但 LLM 天然是个“创造性解释器”，它总会自作主张地补全信息。

排查这类问题时，有用的工具不是看每个 Agent 的输出，而是看信息差异在哪一跳发生的。做法是：在每个交接点上同时保留“上游的原始输入”和“下游实际消费的输入”，对比两者一旦出现显著 token 差异，就要仔细查。顺着这个思路，你往往能定位到某个特别“喜欢润色上游内容”的 Agent——通常这个 Agent 的 Prompt 里有过多的“用自己的话转述”类指令。我们要在工程上严格限制：下游 Agent 对上游输入的解读，只允许显式提取关键字段，不鼓励自由改写。

3.3 多余 Agent 的协调成本：人多不一定快，N 个 Agent 协调是指数级的麻烦

很多团队在引入多智能体时犯一个通病：“任务太复杂，多派几个 Agent 并行处理吧。”但实际上大部分并行场景根本不成立——因为子任务之间存在依赖，并行一多，等待、冲突、上下文复制、互相等锁的时间全涨上来了。

我还算过一笔账：如果系统里有 5 个需要互相通信的 Agent，每对之间都要交换一次信息，那么协调消息数就是 10 条（二维完全联通）；如果有 10 个 Agent，就是 45 条。每条消息背后都有一次甚至多次模型调用、上下文重建成本。我实测过一个 8-Agent 的全互联方案在处理一个中等复杂任务时，token 消耗是单 Agent 串行处理的 11.7 倍，而任务成功率反而下降了近 20%。

所以这里的最佳实践是：不要因为“功能多”而拆 Agent，要因为“边界清晰”才拆。每个 Agent 之间的接口如果不够稳定、职责如果存在重叠，拆得越细，协调成本越高。很多商业项目最终能跑通的多 Agent 系统，往往是 3~6 个边界清晰的 Agent，而不是 20 个互相看着别扭的 Agent。

3.4 上下文污染：一个 Agent 的无关注入，毁了另一个 Agent 的推理

还有一个特别隐蔽但极其常见的问题：为了“给足上下文”，把无关信息也塞给了某个 Agent。LLM 在做长上下文推理时，容易被无关信息干扰，尤其是当无关信息里有“看起来很像指令”的内容时。

我见过一次事故：一个翻译 Agent 在处理某个双语文档时，上游意外把另一份会议纪要的“行动项”部分带了进来。结果翻译 Agent 把“行动项”当作新指令，硬是在任务中途改变了输出格式。排查了很久才发现，问题根源不在翻译 Prompt，而在协作管线里一个“顺手把整个上下文对象直接传给下游”的懒惰实现。

从那以后，我们定了一条规范：每个 Agent 的输入必须由编排器显式裁剪，不允许“顺手把整个 Conversation 传给下一个 Agent”。每个 Agent 拿到的是表单一样的输入，而不是一条冗长的聊天记录。这在工程上叫“最小上下文原则”。别迷信“模型上下文窗口大所以随便塞”，窗口大不等于推理准。

4. 我沉淀下来的工程化最佳实践清单

下面这些条目不是我抄来的，是我们团队在真实项目中踩过坑、反复改过后才定下来的。每一项都能直接搬到你自己系统里。

4.1 给每个 Agent 划“自主边界”：从全自动到双人复核

Agent 系统的设计起点，不是“让 Agent 能做什么”，而是“让 Agent 不准做什么”。我建议把每个 Agent 的自主度分成四档，每一档对应的工程约束完全不同：

我的核心建议是：能让系统跑在 L1~L2 就别硬上 L3。L3 的全自动闭环听着性感，但你必须在后面配一套完善的自动评测机制，不然就是裸奔。很多翻车的 Agent 项目，都是在 L3 上跑着一个没有评测的系统。

4.2 裁判必须和运动员分开

“监督者 / 裁判”不能和执行 Agent 是同一个 Agent——这里的同一个，不仅指同一个模型实例，还指不能用同一个 Prompt 模板衍生。我在项目里就吃过亏：用同一个基座模型分别做了“代码生成 Agent”和“代码评审 Agent”，发现评审 Agent 对生成 Agent 的宽容度高得离谱。后来分析才发现，两个 Prompt 共用了一大段“偏好描述”，评审 Agent 继承了生成 Agent 所偏好的代码风格，于是“自己人审自己人”。

正确做法是：评审 Agent 的 Prompt 必须由另一套上下文构建，尽量不包含生产偏好性意见，只包含硬性的规则清单。如果预算允许，评审 Agent 可以换一个更小的模型或者更强的模型，拿独立系统提示词。再进一步，如果有条件，可以加一层Rule-Based 拦截器：用确定性规则先滤一遍(比如检查结果里是否包含强制性字段），再交给 LLM 做模糊性判断。这比让模型只凭感觉做裁判可靠得多。

4.3 可观测性：每个 Agent 都要能“回放”

多 Agent 系统出问题时，最磨人的状态是“看起来都正常，但结果就是不对劲”。所以，从搭建第一天起就要做 Agent 级 Trace。我会给每一次任务分配一个全局trace_id，在所有 Agent 的消息里带上；每个 Agent 在每次循环里，至少落一条日志，包含当时它看到的上下文摘要、它选择执行的动作、工具返回的结果、它对结果的评估。

为了不让追踪本身成本太高，我在实现里往往只记录“四要素”——Plan（打算做什么）、Action（实际做了什么）、Observation（调用后看到了什么）、Result（产出的物或其引用）。配合前面说的 UI 回放工具，就能像回放视频一样把一次多 Agent 协作从起点到终点的过程重现出来。这个投资非常值：排查问题时能省下 80% 的时间。

4.4 Evaluator 循环：把“好结果”定义清楚再谈优化

多 Agent 系统最重要的一个组件，不是某个业务 Agent，而是评估器（Evaluator）。评估器的作用是跑一套自动化的检查逻辑，对多 Agent 协作的最终产出给分。没有这个组件，你每次改 Prompt 都是在盲调。

我们的做法是构建一套“回归测试集”：把过去三个月线上遇到的所有 bad case 汇总成一批测试用例，每次改完任何 Agent 的 Prompt，都跑一遍这套集子，看有没有把以前修好的问题又带回来。这套测试集某种程度上比模型本身还宝贵，因为它承载的是“这个系统在生产环境长什么样”的经验。

在评估维度上，我习惯拆成两层：内容质量层（准确性、完整性、风格一致性）和流程合规层（有没有越过权限边界、有没有经过必要审批、每个 Agent 的置信度是否达标）。很多团队只评内容不评流程，结果内容看起来好，但根本没法上线——因为流程层不满足合规要求。

4.5 逃生门设计：允许 Agent 说“我不知道”

越复杂的 Agent，越容易在遇到认知边界时强行给出一个看似合理的答案。为了对抗这种倾向，我会给每个 Agent 的返回结构里加一个特殊字段：need_human_input: boolean。当 Agent 的置信度极低、或者输入上下文缺失关键信息时，它应主动上报主管，而不是硬着头皮继续操作。

这个设计看起来简单，做起来不容易，因为它是跟模型天性反着来的——模型天然被训练成“永远补充完整”。所以我在 Prompt 里不仅要求它“没把握就说”，还会在评估指标里加一条：“主动求助率”。一个 Agent 如果从没求助过，我会怀疑它是不是在逞强。生产环境的经验是，主动求助率控制在 5%~15% 之间比较健康，太高说明上游没喂够信息，太低说明它有硬编的嫌疑。

5. 从演示项目到生产系统的落地路线

最后一个部分，聊一聊如果把一章的理论落进真实项目，正确顺序是什么。这部分也是我们踩过最多坑的地方。

5.1 先让单体流程跑通，再拆协作

我的顺序建议可能与很多人的直觉相反：多 Agent 系统上线前，先用单 Agent 把业务逻辑跑通。什么意思呢？就是把整个流程全部塞到一个超长 Prompt 里，先让它把主链路走通。这个阶段的目的是让你搞清楚两个关键信息：流程的每一步到底需要什么输入、每一步可能在哪些环节出错。这些信息是后面设计 Agent 分工的依据。

如果连单 Agent 都跑不通解锁的流程，你拆成多 Agent 一定会更复杂。很多人上来就拆三个 Agent，结果问题全在编排层，根本到不了业务层。白费功夫且浪费时间。正确顺序是：

1. 用单体 Agent 做完整个流程，记录断点；
2. 根据断点和上下文风格差异，判断哪些环节值得独立成 Agent；
3. 设计消息协议和状态边界；
4. 先接两个 Agent，跑通后再逐步加节点。

我们团队现在做新项目基本都走这条路径，实际效率高很多——“拆开”永远比“组装”容易，你得先有一个能组装的整体。

5.2 Prompt 即代码：版本管理、评审与回归

多 Agent 系统的核心资产不是模型权重，是Prompt + 编排配置 + 测试集。这三样东西必须纳入版本管理，和代码一样走 Code Review 和发布流程。

我见过太多团队这样做：Prompt 在 Team 里线上改完即用，完全脱离版本控制。问题是，改了一个 Prompt，往往会影响整个链路下游所有 Agent 的输入输出分布——你必须在发布前跑一遍回归用例，确认影响边界。我的建议是：Prompt 文件放入 Git 仓库并做 diff review，编排配置（消息协议版本、路由规则、Agent 注册表）也入库；每次变更合入前，强制跑一次自动化回归测试集。这套纪律看起来“重”，但一旦踩过“线上改 Prompt 导致全链路崩溃”的坑，你就会理解为什么必须重。

5.3 不同行业的落地场景差异：从电网到医疗，从群集控制到内容生产

多智能体协作不是 AI 行业的专利，很多硬核工程领域早就跑了几十年类似的架构。我接触过几个典型场景，都印证了同一个方法论骨架：

电力系统的多智能体协同。电网可靠性分析里，不同区域的智能体负责各自片区负荷预测和故障预判，再把结果汇总到调度中枢做全局评估。这种场景强约束、高实时性，Agent 的自主度必须非常低，每一层决策都必须带置信度和依据，而且必须有沙盘演练机制——引入虚拟故障数据来训练各 Agent 之间的配合策略。这个场景和 AI Agent 的共性在于：多智能体协同的价值不是“自动化”，而是“隔离能力+局部自治+跨区协调”。

医疗领域的多专科协作。最近医疗 AI 方向有很多多智能体项目，比如中医辅助诊疗系统，把症状采集、辨证分析、方剂匹配、禁忌核查拆成不同的 Agent。这个场景的专业隔离非常重要——不能一个 Agent 既管望闻问切又管开方，出了问题没法定责。工程化上必须做到每一步决策都被单独评审记录，且能回溯到某条知识来源。这也是为什么医疗领域特别强调“每个 Agent 的边界要清晰”。

群集运动控制和机器人调度。无人机编队表演、仓储机器人搬运这类场景，本质上每个机器人就是一个 Agent，与 AI Agent 不同的是它的反馈回路是物理世界信号（视觉定位、距离传感器）。这类系统的 Loop Engineering 更严格：每个机器人的局部决策都要实时广播、群集共识算法保证整体不冲突。从中层抽象的眼光看，和编排器编排几个 LLM Agent 解决问题的方式非常相似，只是通信协议从 JSON 换成了 ROS 这类消息总线。这块涉及的“协同群集运动控制”相关研究非常扎实，组织行为、邻居状态协商、一致性协议，比 AI Agent 领域成熟得多——值得做多 Agent 的人去借鉴。

5.4 团队工程纪律：多智能体是组织问题，不是模型问题

最后我想说一句可能不太好听、但确实是实践出来的结论：多智能体系统崩掉，绝大多数情况不是模型太笨，是工程纪律不够。团队里没有自动测试、没有版本管理、没有结构化通信、没有可观测性，用再强的模型也白搭。

我建议每个准备做多智能体系统的团队，先在白板上画清楚三张图：协作拓扑图（谁给谁派活、谁向谁汇报）、状态流图（哪些状态是可共享的、哪些是私有的）、异常流图（哪一步出了错，错误信号怎么回流）。三张图画不出来，就说明你对系统的理解还停留在“角色扮演”阶段，而不是工程化阶段。等你想明白这些问题，Loop Engineering 的价值自然就体现出来了。

从我的亲身体验来说，真正跑过多套多智能体工程之后，最大的体会是：智能体的“智能”只占一半，另一半是循环有没有闭合。单 Agent 再聪明，协作系统里没有信息回流、没有置信度检测、没有评审隔离、没有办法回放过程，它就只是一堆各自聪明的孤岛，而不是一个系统。你先去把反馈的闭环跑通，再去考虑加新的 Agent——这个顺序，值得刻在项目白板上。