企业官网建设流程全解析

1. 从“对话机器人”到“Agentic系统”：为什么需要设计模式

1.1 传统LLM应用的天花板

我在接手Ynuo Agent（依诺）这个项目之前，带团队做过不少大模型应用。早期的那些项目，说白了就是“给大模型套一层壳”：用户输入一句话，程序拼接一个Prompt，调用一次模型接口，拿到回复后原样展示。这种模式在演示阶段很好看，一进入真实业务环境就露馅了——它只能回答问题，不能解决问题。用户说“帮我查一下上个月的订单数据，做一份销售趋势分析，然后把异常点标出来，最后写一封给区域经理的邮件”，传统应用只能做到第一步“查一下”。后面的分析、标注、邮件撰写，每一步都涉及工具调用、中间结果校验、格式转换，靠一段Prompt根本串不起来。

问题的本质在于：大模型本身没有“行动能力”。它像一个只出主意不动手的顾问，知识丰富、表达流畅，但无法操作数据库、不能调用内部API、不会自己去验证一个数据到底准不准。要想让模型真正完成一个完整任务，就必须在它周围搭建一套具备感知、决策、执行、反馈闭环的系统。这套系统该怎么搭、各模块之间怎么协作、遇到异常怎么兜底，这些规律性的解法，就是Agentic设计模式要回答的问题。

1.2 Agentic设计模式到底是什么

Agentic设计模式，核心就一句话：把大模型从“文本生成器”改造成“任务执行者”的方法论集合。它不是某个算法，也不是某段代码，而是一套被反复验证过的架构范式。最基础的模式包括：

• ReAct模式：让模型在“推理”和“行动”之间交替，每做一步就观察结果，再决定下一步；
• 规划-执行模式：先让模型拆解出完整计划，再逐步执行每一个子任务；
• 反射模式：让模型对自己的输出进行自查和修正，减少低级错误；
• 多Agent协作模式：几个分工不同的Agent互相配合、互相审核，完成单个Agent搞不定的复杂任务。

以前我们写业务系统，有MVC、分层架构、微服务这些设计模式；《设计模式》那本书里讲的是面向对象编程的套路。到了大模型时代，系统的核心变成了“一个会思考的模型加上一堆外部工具”，思考怎么编排、工具怎么接入、状态怎么管理、错误怎么恢复，这些套路就是Agentic设计模式。Ynuo Agent这个项目的重要目标之一，就是把上述这些模式工程化、产品化，让开发者不用从零手写每个循环和状态机。

1.3 Ynuo Agent（依诺）的定位与适合人群

Ynuo Agent（依诺）在我手里是一个面向复杂任务编排的轻量级Agent框架。它的设计思路很直白：用配置和少量代码，快速组装出一个有目标、有工具、有记忆、会自主行动的Agent系统。它可以是一个自动写周报并发送邮件的助理，也可以是一个汇集多个数据源的分析顾问，还可以是一组互相评审的“虚拟团队”。

什么场景适合用这套东西？我的判断标准有三条。第一，任务不是一次Prompt能完成的，需要多轮工具调用才能拿到结果；第二，执行链路中存在条件分支，需要根据中间结果动态调整路径；第三，用户希望系统在无人盯守的情况下自动跑完整个流程。反过来，如果只是闲聊、翻译、单轮问答，没必要上Agentic设计模式，直接用模型接口就好，引入Agent框架反而增加延迟和复杂度。适合阅读本文的读者，是那些准备把LLM应用从“demo”推向“生产”的开发者，以及正在选型Agent框架的技术负责人。我会结合Ynuo Agent在真实业务中的落地细节，把Agentic设计模式逐层拆开讲清楚，包括原理、代码、踩坑和调试方法。

2. Agentic设计模式的核心图谱与选型思路

2.1 先理清五类基础模式

在给Ynuo Agent加入一个新业务模块时，我通常会先做一次“模式识别”：这个任务最贴近哪一类Agentic设计模式。下面这五类是我使用频率最高的。

第一类：ReAct模式。让模型在“思考-行动-观察”之间循环。把它理解为“摸着石头过河”：模型先生成一个想法（Re），再调用一个工具（Act），然后根据工具返回值修正认知（Observe），再进入下一轮思考。它的优点是灵活，遇到新情况能随时调整；缺点是如果模型本身推理能力弱，或者工具返回信息太杂乱，容易出现反复原地打转。

第二类：规划-执行模式（Plan-and-Execute）。先把任务一次性拆成步骤清单，然后按清单逐项执行。适合那些目标明确、步骤相对固定的任务。比如“从某处下载文件，清洗数据，做几张图，发一封邮件”这种流程，中间没有太多意外分支，规划一次就能跑完。总结成一句话：ReAct是边走边看，规划-执行是先想好再走。

第三类：反射模式（Reflection）。让模型对自己的输出做一轮“批判性审查”。以前我在Ynuo Agent里实现了一个“写代码-自检-修复”的循环：Agent写好一段脚本，不直接执行，先交给另一个检测步骤检查语法和潜在逻辑漏洞，发现问题就交给原Agent修改，再检查，直到通过。这个模式非常适合生成任务、代码生成、报告撰写这些容易“一本正经胡说八道”的场景。

第四类：多Agent协作。把一个复杂任务拆开，交给多个各有专长的Agent。我曾经在一家做供应链数据的某公司接触过类似方案：一个Agent负责抓取库存信息，一个负责做销售预测，还有一个专门负责挑毛病，检查前面两个的输出有没有矛盾。这三个Agent之间通过消息池异步通信，各干各的，互不阻塞。多Agent的核心收益是“专业化分工”，但代价是通信成本高、状态一致性难维护。

第五类：人机协同模式（Human-in-the-loop）。在关键节点暂停，让人确认后再继续。比如自动发邮件之前、扣款之前。很多Agent系统都在追求“完全自动”，但涉及高影响动作时，保留一个人工确认环节反而能大幅提升整体成功率。Ynuo Agent在设计时就把“问一次人”视为一个标准动作。

2.2 模式的组合：大多数项目没有“银弹”

在实际项目里，单一模式很难覆盖复杂任务，更多时候是按需组合。我总结过一种比较典型的“三段式组合”，在Ynuo Agent里广泛使用：

1. 规划阶段：使用规划-执行模式，让主Agent先输出一份任务清单；
2. 执行阶段：对清单中的每一项，动态切换成ReAct模式，边调工具边观察结果；
3. 收尾阶段：启用反射模式，让一个独立的审查环节检查最终产物。

举个具体例子。团队里某同学用Ynuo Agent搭建过一个“招投标文件合规检查”工具。主Agent先规划出检查维度（资质文件、价格构成、技术响应等），每个维度交给一个子Agent执行，子Agent用ReAct模式反复查询文件库并核对条款，最后再由一个“审查Agent”对所有检查结果做交叉验证，输出合规报告并标注风险等级。如果从头到尾只用一个模式，要么灵活性不够（纯规划-执行遇到漏项不会应变），要么稳定性不够（纯ReAct容易出现分支失控）。

下面这张表是我在做技术选型时经常参考的，也分享给读者：

2.3 选型决策：Ynuo Agent内部怎么判断

经常有人问我：“这个任务要上几个Agent才合适？”我的回答通常是四个字：够用就好。在Ynuo Agent里，我们会根据三个维度去做“模式数量”的决策。

第一个维度是任务的不确定性。如果一个任务的所有步骤在开始前就能全部列举出来，比如报表定时生成，那就不需要给Agent太强的推理自由度，直接走规划-执行模式，甚至提前固化成工作流。如果任务会随着中间结果而变化，比如“先查库存，库存不够就询价”，那必须让Agent具备ReAct式循环能力。

第二个维度是错误容忍度。输出可以稍微粗糙、后面有人会审核的任务，尽量不要做反射层，省一次调用成本。输出直接面向客户、无法人工返工的任务，反射模式是值得上的。我在Ynuo Agent里的一条经验是：反射模式执行得太多，模型有时会把本来正确的答案“改错”，所以通常限制自检次数为两轮，超过就人工介入。

第三个维度是并行度。多个子任务互不依赖时，优先用多Agent并行，整体耗时会从加法变成取最大。例如从前需要依次处理三个城市的数据，如果三个城市完全独立，就拆成三个Worker并行执行，用调度器汇总结果。如果子任务之间有强依赖关系，强行拆开只会增加通信负担，不如让一个Agent串行跑完。

3. Ynuo Agent的核心组件：用配置管理Agentic循环

3.1 会话状态机：Agentic循环的骨架

Agentic设计模式和普通函数调用最大的区别在于有状态。一次任务执行过程中，系统需要记住模型思考到哪一步、用过哪些工具、拿到了什么结果、下一步还有哪些候选动作。Ynuo Agent内部用一个状态机来管理这些信息，核心状态包括：

• IDLE：空闲状态，等待新任务；
• PLANNING：规划中，模型正在拆解任务；
• EXECUTING：执行中，正在调用工具或模型推理；
• WAITING_INPUT：等待用户输入，通常出现在人机协同节点；
• REFLECTING：自检中，审查Agent正在审计输出；
• COMPLETED/FAILED：结束状态。

实现这个状态机并不需要引入重量级框架。我在Ynuo Agent的早期版本里只用一个简单的类来维护当前状态和转移条件，看起来像这样：

class AgentStateMachine: def __init__(self, initial="IDLE"): self.state = initial self.history = [] self.tool_results = [] def transition(self, event): # event 可能是 plan_finished / tool_result_received / user_confirmed 等 rules = { ("IDLE", "start"): "PLANNING", ("PLANNING", "plan_finished"): "EXECUTING", ("EXECUTING", "tool_result_received"): "EXECUTING", ("EXECUTING", "needs_confirmation"): "WAITING_INPUT", ("EXECUTING", "all_steps_done"): "REFLECTING", ("WAITING_INPUT", "user_confirmed"): "EXECUTING", ("REFLECTING", "review_passed"): "COMPLETED", ("REFLECTING", "review_failed"): "EXECUTING", } key = (self.state, event) if key in rules: self.state = rules[key] self.history.append((self.state, event)) else: raise ValueError(f"Illegal transition: {self.state} -> {event}")

状态机的好处是让Agent的行为变得可追踪。在Ynuo Agent的调试面板里，每一条历史记录都对应一次状态转移，用户可以看到Agent现在卡在哪个环节，是规划不出来、工具调用失败，还是在等人确认。没有这套机制之前，Agent跑挂了就只能翻日志“猜”原因。

3.2 工具调用层：Agent的“手脚”

没有工具的Agent只是“会思考的嘴”，有了工具，模型才真正获得行动能力。Ynuo Agent的工具层设计遵循三个原则。

第一个原则是工具注册标准化。每个工具必须声明名字、描述、参数结构、返回结构。Ynuo Agent的工具注册代码长这样：

def register_tool(tool_name: str, description: str, parameters_schema: dict, handler_fn): """向Agent运行时注册一个可用工具。""" tool_registry[tool_name] = { "name": tool_name, "description": description, "parameters_schema": parameters_schema, "handler": handler_fn, }

为什么要这样做？因为模型在决定调用什么工具时，依赖的是“工具的名字和描述”，它不会直接执行你的Python函数。描述写得好不好，直接影响模型选工具的准确率。我见过很多项目把工具描述写成一行字，模型根本不知道这个工具适合什么任务，最后乱调一气。我的经验是，描述里一定要包含：工具解决什么问题、典型输入长什么样、常见坑是什么。

第二个原则是参数强校验。模型生成工具参数时经常出现幻觉，比如日期格式写成“2023/13/45”，或者把单位写错。Ynuo Agent在调用任何工具之前，会先用参数的JSON Schema做一次强校验，不通过就打回让模型重新生成，而不是直接把错误参数丢给底层函数——底层函数跑出一个莫名其妙的异常，排查成本反而更高。

第三个原则是超时与降级。每个工具调用都要设置超时时间。外部API超过5秒没返回，Agent可以决定重试、换方案或者放弃，但绝不能在无响应的情况下死等一下午。我见过一个线上问题：Agent调用某个内部服务时接口假死，每次超时默认重试三次，但三次全部超时之后没有任何降级策略，任务就卡死了。后来我们在Ynuo Agent里给工具层加了一个“失败后降级”的配置：查数据库失败，可以尝试查询缓存副本；发邮件失败，可以降级为本地保存草稿。

3.3 记忆分层：让Agent不“失忆”

Agentic系统经常被吐槽“像金鱼一样，只有七秒记忆”。这个问题的根源在于语言模型的上下文窗口有限，每次调用都只能看到窗口内的文本。要应对这个问题，Ynuo Agent把记忆拆成三层。

第一层是短期记忆，记录当前任务的主干信息：目标、已完成步骤、最近的工具返回、当前待办。这一层存放在会话变量里，直接注入下一次大模型调用的上下文。短期记忆要“精炼”，因为上下文窗口是稀缺资源，不能把工具返回的原始长文本全都塞进去，需要先做截断和摘要。比如一个工具返回了50行JSON，Ynuo Agent会在注入上下文前先压缩成3~5行的要点。

第二层是长期记忆，记录跨会话的偏好、历史反馈、常见模式。比如用户多次要求“邮件签名放在最后”，这个偏好应该从第一次出现时就被提取出来，存进长期记忆库，后续所有邮件相关任务都带着这条偏好走。在Ynuo Agent里，长期记忆是用一条独立的向量检索流程管理的，每次任务开始时先查询一遍相关记忆，再拼进系统提示词。

第三层是脚本记忆，适用于那些步骤完全封闭的重复任务。既然任务可以提前自动化，就不需要每次重新“思考”，直接把脚本记忆成一条任务模板，下次按模板执行。我见过某电商团队使用Ynuo Agent处理“待发货订单自动查库存”，首周每天跑一遍ReAct循环，第二周就把流程固化成了脚本记忆，单次执行时间缩短了40%。

3.4 人机协同节点：Agent不是越自动越好

Ynuo Agent里有一个最容易被新手忽略的配置项——“确认门槛”。它定义了哪些动作需要经过人工确认才能继续。我的做法是，把所有工具动作按风险等级分成三类：

• 低风险动作：查询、读取、计算、草稿生成，默认放行；
• 中风险动作：写入、修改、发送，默认要求一次确认；
• 高风险动作：删除、批量操作、扣费，必须双重确认。

这种设计很反直觉：很多开发者觉得Agent越自动越先进。但真实场景里，模型误操作造成的损失远大于人工介入的延迟成本。某次Ynuo Agent在测试环境自动发送了一百多封测试邮件，就是因为“发送邮件”没设确认门槛，一个参数错误导致收件人全乱套了。从那之后，我们所有涉及外发的动作默认挂上WAITING_INPUT状态，用户在确认面板看到详细内容再点同意。

4. 实操过程：用Ynuo Agent搭一个Agentic业务案例

4.1 定义业务目标与Agent角色

这一部分我会完整演示一次用Ynuo Agent搭建“门店销售日报自动生成与发送”的过程。之所以选这个案例，是因为它同时覆盖了规划、工具调用、记忆、人机协同、反射五种模式，足够有代表性。

业务目标描述为：每天晚上10点，自动读取当天各门店的销售数据，生成一份Markdown日报，内容包括总销售额、环比变化、Top3热销商品、异常门店提示，并以邮件形式发送给管理层。如果发现销售额环比下降超过20%的门店，还需要在日报中额外生成一段原因分析，并附上建议动作。

在Ynuo Agent里，定义一个Agent需要提供角色描述、目标、可用工具、记忆策略、确认规则。下面是一份简化版的Agent配置：

agent: name: store_daily_reporter role: 门店销售数据分析助理 objective: 每天生成销售日报并发送给管理层 tools: - read_sales_data - calc_ring_ratio - query_product_rank - get_store_exception - send_email memory: short_term: max_steps: 10 long_term: enabled: true topics: [report_preference, format_preferences] confirmation_rules: send_email: always reflection: enabled: true max_rounds: 1

这里有两个值得关注的细节。第一个是tools字段里没有选择无限多的工具，而是只暴露了五个。工具越多，模型选错的概率越大，Ynuo Agent的默认建议是“一个Agent最多挂8~12个常用工具”。第二个是confirmation_rules.send_email: always，别嫌它多余，这一步能避免多少误发送事故，长期跑过的人心里都有数。

4.2 配置工具与知识源

工具层是这次搭建过程的核心。read_sales_data工具的注册逻辑，我贴一段关键代码：

async def read_sales_data(date: str, store_ids: list[str]) -> dict: """读取指定日期、指定门店的销售明细汇总。""" raw_df = await query_dw_table("sales_fact_table", date=date, store_ids=store_ids) summary = { "date": date, "total_sales": raw_df["amount"].sum(), "order_count": raw_df["orders"].sum(), "store_breakdown": raw_df.groupby("store_id")["amount"].sum().to_dict(), } return summary register_tool( tool_name="read_sales_data", description="读取指定门店在指定日期的销售汇总数据，包含总销售额、订单数、分店销售额。用于制作销售日报。", parameters_schema={ "type": "object", "properties": { "date": {"type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}$"}, "store_ids": {"type": "array", "items": {"type": "string"}}, }, "required": ["date"], }, handler_fn=read_sales_data, )

关于参数Schema，后面这条经验会省掉很多调试时间：pattern字段一定要加。模型生成日期时如果不加正则约束，它有可能给出“昨天”“2024/3/9”这类无法解析的内容，工具就会在第一个参数校验关卡被拦下。校验失败的信息会反馈给模型，模型再重新生成一次，多了一轮重试消耗，但比跑到数据仓库里报错要轻得多。

知识源指的是Agent可以参考的外部信息，比如门店的基准销售额、商品分类表、历史活动记录。Ynuo Agent支持把知识源作为长期记忆注入，也可以把知识源装进一个可检索的工具里，做成“ask_knowledge_base”。我推荐后者，因为知识库内容通常很长，全部塞进上下文既浪费token又会干扰模型对当前任务的注意力；做成检索工具后，只有模型主动查询时才会注入相关内容。

4.3 编排多步执行链路

任务开始后，Ynuo Agent内部会生成一个执行计划。为了让大家看懂，我会把一次完整运行时的“思维链条”抽象成下面的步骤序列：

1. 主Agent进入PLANNING状态，调用规划模块，生成四步计划：读取销售数据、计算环比、提取商品排名、扫描异常门店；
2. 状态转移为EXECUTING，依次调用read_sales_data("2025-01-15", null)，获取全体门店数据；
3. 调用calc_ring_ratio，对比前一日的销售额，算出环比变化；
4. 调用query_product_rank，按销售额倒序查出前三热销商品；
5. 调用get_store_exception，筛选出环比下降超过20%的门店；
6. 发现有两家异常门店，Agent进入“补充分析”分支：查询长期记忆里是否存在类似历史事件，如果有相似案例，就参考当时的应对动作生成分析文字；
7. 生成日报Markdown草稿，进入REFLECTING状态，审查Agent检查格式、数字是否一致，发现一处数字错误（某门店销售额单位被写成万元而非元），退回修改；
8. 修改完成后，Agent停到WAITING_INPUT状态，弹出邮件预览，等待管理员确认；
9. 管理员确认后，调用send_email，任务标记为COMPLETED。

这个链路不复杂，但包含了Agentic设计模式中的三个关键要素：动态分支（第6步）、自我修正（第7步）、人工确认（第8步）。如果一开始就把所有步骤写死成固定流程，第6步就会缺失；如果没有反射层，第7步的错误就会被直接带进正式邮件；如果没有确认节点，第8步之后就会发生一起可以避免的误操作。

4.4 调试与可视化

Ynuo Agent会记录每一步的输入输出和状态转移，在调试面板里我常做三件事。

第一件事是看“步骤耗时分布”。如果时间大量消耗在模型调用上，说明推理次数太多，需要检查是不是工具返回的信息不够清晰，导致模型反复尝试；如果时间消耗在工具本身，则考虑加缓存或优化查询条件。

第二件事是逐条回放“模型决策”。Ynuo Agent会把每次模型调用的完整Prompt和响应存下来。我经常在模型做错误决策时打开这条记录，看它到底被哪段上下文误导了。比如有一次模型反复调用get_store_exception，就是不进入下一步，后来发现是工具返回里没有“门店-环比-天数”三个字段，模型判断不了异常程度，只能继续查询。补齐返回字段后，问题自然消失。

第三件事是“平行对比调试”。同一个任务，分别用ReAct模式和规划-执行模式各跑一遍，对比成功率、执行时间、成本。Ynuo Agent支持在一次任务里记录模式标签，方便后续用统计报表做对比分析。我就用这种方法发现，我们某条业务链路上的最佳配置组合是“规划-执行+一层反射”，而不是“纯ReAct+两层反射”。

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

5.1 问题一：Agent陷入“循环空转”停不下来

症状是日志里反复出现同一个工具调用，或者模型在同一个分支上不断调自己的输出，停留在同一个状态很久。

排查方向有三。第一，工具返回的信息是否让模型产生了“信息不足”的误判。我之前遇到过一次，一个查询接口每次只返回前十条记录，模型想拿到全部数据，于是反复用不同参数调用，但每次都被分页限制挡住。解决方案是给工具加一个has_more字段，明确告知是否还有下一页。第二，检查是不是上下文被截断导致模型看不到之前的决策。短期记忆只保留最近几步，Earlier的决策被挤掉后，模型可能“失忆”重新走老路。这种情况要适当扩大短期记忆容量，或者强制模型每轮先总结当前进度。第三，工具的返回包含Noise，模型把错误信息当作有效信号，反复尝试纠正一个并不存在的问题。改进方法是让工具层对返回做一次预处理，过滤掉无意义的字段。

从机制上避免空转，Ynuo Agent里有两个参数值得设置：max_rounds限制最大循环轮数，超过强制停机并进入人工处理；duplicate_call_detection检测重复的工具调用，如果连续三次调用同工具且参数完全一致，判定为空转，改为要求模型重新说明意图。

5.2 问题二：工具参数幻觉导致调用失败

模型生成的参数跟实际情况对不上，是最高发的问题。比如模型生成店名时写错了门店编码，或者在日期上多了一个小时偏移。这类问题表面上是模型不够聪明，实际上是工具定义没做到位。

我的排查顺序是：先把模型生成的原始参数和工具Schema拿出来比一遍，看哪个字段和定义不匹配；然后在工具描述里补充可能被误解的信息，比如“store_id指的是六位数字编码，不是门店中文名”；最后，如果模型还是反复错，就在参数校验失败时把错误原因原样返回给模型，让它自己改正。某开发者还在Ynuo Agent里加了一个“few-shot示例”，在工具描述中附带一个真实的输入样例，参数准确率从70%提到92%。

5.3 问题三：上下文窗口溢出与记忆丢失

任务过长、工具返回过大时，上下文窗口很快被占满。Ynuo Agent的策略是“分层压缩”：工具返回先摘要，单步历史只保留动作和结果要点，长任务开启定期总结节点。我见过最夸张的一个案例，一个Agent连续运行了42个步骤，如果每一步都保留完整工具返回，早就超出窗口上限了。加了总结节点后，每跑五步模型自动写一段“当前进度小结”，然后清掉之前的详细记录。这个做法损失了一些细粒度信息，但换来了任务能稳定跑完。

5.4 问题四：多Agent之间的重复劳动与矛盾决策

多Agent模式下，最常见的坑是两个Worker处理了同一个子任务，导致重复计算；以及两个Agent在同一问题上给出不同结论，汇总时无法抉择。

Ynuo Agent的解决办法是：给每个子任务加上全局唯一的任务ID，Worker在认领任务时先锁ID，防止重复；同时在调度层引入“结论冲突检测”。当两个Agent对同一指标给出不同判断时，调度器不盲目信任某一个，而是把两者差异交给第三个“裁决Agent”或者直接请求人工确认。我在前面提到的招投标合规检查工具里，就是把冲突规则设定为“如果两个Agent结论不一致，默认人工复核”，宁慢勿错。

5.5 附一张快速排查速查表

6. 我个人在Ynuo Agent落地中的几点体会

做了这么久的Agentic系统，我最深的一个体会是：设计模式的意义不是让人把代码写得更炫，而是让系统在失控之前有章可循。新手拿到Agentic设计模式，很容易把它当作“让模型更自主”的催化剂，结果搭出来的系统越发不可控。我的建议恰恰相反，要把Agent理解成一个“能力很强但需要约束的员工”：给它清晰的工具边界、可回溯的状态、必要的审批节点，它才能稳定输出价值。

还有一点想特别提醒：不要为了用模式而用模式。如果你发现某个任务用一次Prompt加两次工具调用就能完成，那就不需要硬套一个复杂的多Agent架构。Ynuo Agent里我见过很多失败的配置，不是因为模式选错了，而是模式堆太多了。一个日报生成任务，硬拆成了五个Agent互相审核，结果跑一次要五分钟，还经常因为消息传递延迟导致数据不一致。后来我把它们合并成一个主Agent加一个审查Agent，既快又稳，效果反而更好。

最后分享一个判断标准：模式的好坏，不取决于它多花哨，而取决于它在出错时能否快速定位问题。我在Ynuo Agent上踩过的坑，几乎都集中在“失控之后不知道责任在哪一层”。所以无论采用哪种设计模式，状态机、日志、可复现的调试记录这三样基础能力一定要有。没有这三样，Agent跑得再快，也像在黑夜里的高速上开车，危险随时会出现。希望这篇文章能帮正在做Agent开发的同学少走几步弯路，哪怕只有一条排查经验用得上，也算值得了。