从2024年拿来练手的单Agent到现在被业务方追着问“能不能让两个Agent自己配合把活干了”这个变化其实也就一两年的时间。我自己从最早用一个大型语言模型加提示词硬刚所有任务到后来拆出规划器、执行器、记忆模块再到现在维护着一套包含多个专职Agent的协同系统踩过的坑可以说不比写过的代码少。这篇文章想聊的就是基于2026年这个时间点上我对AI Agent架构设计的一些实操经验和思考。核心是回答几个问题单模型架构的边界到底在哪多智能体协同是不是真的有必要如果要用该怎么设计才不会变成四不像的分布式灾难文中也会用一个很常见的“企业问数智能体”作为实战案例走一遍从单模型到多Agent协同的完整演进路径。适合正在做大模型应用落地、或者准备从单体Agent迁移到多Agent架构的工程师也适合那些想从0到1搭建AI Agent但又不想一上来就堆砌一堆框架的人。1. 整体设计思路为什么单模型Agent会先到天花板1.1 单模型Agent的能力边界很多团队刚开始做AI Agent都是用一个强大的基础模型通过System Prompt定义角色再挂上几个函数调用来完成工具使用。这个思路在Demo阶段非常爽一周就能跑通一个“让AI帮我查库存”的演示。但一旦放到生产环境它的瓶颈会以肉眼可见的速度暴露。先说最直观的上下文窗口再大也架不住多轮任务中的过程信息膨胀。一次复杂的数据分析任务模型需要先拆解问题、再查询多个数据源、中间可能还要调整SQL、最后生成结论。每一步的中间结果都要塞进上下文一个长会话搞下来几万Token就没了。更麻烦的是模型自己很难判断哪些信息该丢弃、哪些该保留经常出现“把工具返回的几百行原始数据全留着把用户最初的目标给忘了”的情况。然后是工具调用的稳定性问题。单一模型既要做语义理解又要做任务规划还要做工具参数抽取所有责任压在一个模型上。任何一个环节出错整个链路就崩。我见过很多单Agent项目模型在调用日期参数时一会儿输出“2026-01-01”一会儿输出“20260101”或者把“上周”理解成字符串而不是一个日期范围。这些错误不是模型能力不够而是同一个模型承担的职责过重导致注意力被分散。还有一个被很多人忽略的问题单模型Agent的扩展性很差。你想加一个新的工具就得改System Prompt然后回到测试回归。你想给不同业务方提供不同的Agent那就得复制一堆几乎一样的Agent实例最后改一个公共逻辑要同步改十几个地方。这种方案在Agent数量少的时候还能忍一旦超过5个维护成本就会指数级上升。1.2 多智能体协同的出现逻辑多智能体协同不是某个框架发明的概念而是对现实协作模式的一种映射。大型任务天然适合拆分拆分之后的子任务需要专业的执行者执行者之间需要沟通和协调。在AI系统里“智能体”就是这种执行者“多智能体协同”就是让它们像一支团队那样工作。从工程维度看多智能体协同带来的核心收益有三个。第一是职责隔离每个Agent只做一件事模型的压力小准确率自然高。第二是容错某个Agent挂了或者返回结果不合格可以由协调者重新调度不会整个任务报废。第三是并行多个独立子任务可以同时执行整体时延从“串行的总时长”变成“最长分支的时长”。但多智能体协同不是银弹。它引入了新的复杂性Agent之间的通信协议怎么定任务怎么拆谁来拆如何保证共享状态的一致性如何处理重复执行导致的结果冲突这些问题如果设计不当最后得到的不是一支团队而是一个比单模型还要混乱的分布式大泥球。我自己的观点是多智能体架构只有在任务复杂度、工具数量、业务边界都达到一定阈值之后才开始划算。阈值怎么判断我的经验是如果你当前的单一Agent的Prompt超过3000字、工具数量超过10个、或者经常因为“模型无法同时兼顾意图判断和参数抽取”而出错那就应该认真考虑拆分了。1.3 2026年的架构趋势从“大而全”到“小而专”2026年的主流做法已经不是用一个超强模型包打天下也不是让一堆Agent自由混战。更务实的路线是“分层协作”加“专业Agent编排”。你可以把系统分为三层最外层是入口Agent负责理解用户的模糊需求判断任务类型把它转成结构化的任务描述中间层是协调者负责拆解任务、分配子任务、汇总结果最内层是执行者负责具体工具调用、数据查询、代码执行等原子操作。这种分层结构的好处是每一层都可以独立演进。入口Agent可以专注于意图理解和交互体验协调者可以专注于任务规划与状态管理执行者可以专注于工具调用精度。任何一层的Prompt、模型或逻辑发生变化都不需要其他层跟着改。2. 核心细节解析与实操要点单模型Agent的基础架构怎么搭2.1 Agent内部的四段式循环无论最后是多智能体还是单模型Agent内部基本逃不开“感知-规划-行动-反馈”这个循环。用工程术语说就是接收输入形成计划调用工具处理结果。一个扎实的单模型Agent至少要把这四个环节的代码结构和Prompt设计做到位否则后面的多Agent协同就是空中楼阁。感知环节的重心在意图识别和参数提取。很多团队会在这一步就调用模型做一次“预处理”把用户输入的“帮我看看今年第一季度华东区的销售额对比上个季度”提取成结构化的查询请求时间范围2026-01-01到2026-03-31、区域华东、指标销售额、对比对象上季度。这个预处理动作看似多花了一次模型调用却能大幅减轻后续任务规划的压力。规划环节最常见的做法是让模型输出一组步骤每个步骤对应一个工具调用。这里一定要约束输出格式最好是JSON结构并明确每个步骤的输入输出依赖。不必用复杂的“ReAct”框架只要坚持“一次只做一步步与步之间传递结构化状态”就能解决大多数问题。行动环节就是执行工具调用。要注意的是工具调用的结果往往是不确定的。比如查询数据库可能返回空结果调用外部API可能超时。Agent需要有能力处理“执行失败”的情况而不是直接报错退出。在这一环节我强烈建议增加一个“错误重试”机制但要限制重试次数防止模型陷入死循环。反馈环节是把工具执行结果送回到模型上下文里并让模型判断是否需要继续下一步还是可以直接给出最终答案。反馈环节最容易犯的错是把所有工具返回内容原封不动地塞进上下文。应该设计一套“结果压缩”机制比如只保留前50行、只提取统计摘要、只返回错误码和关键信息这样既能保住关键信息又不会让上下文爆炸。2.2 记忆与上下文管理最容易踩的坑单模型Agent最常见的崩溃原因不是模型能力不够而是上下文管理一塌糊涂。很多人的写法就是把历史对话、工具输出、中间思考全部堆在一个messages数组里多久都不清一次。等上下文长度逼近模型上限要么报错要么模型开始胡说八道。我的建议是给Agent划分三种记忆短期对话记忆、工作上下文记忆、长期知识记忆。短期对话记忆只保留最近几轮用户输入和Agent响应用于维持对话的连贯性。工作上下文记忆是当前任务执行过程中的临时状态包括子任务列表、已完成的步骤、中间结果等任务结束后即可清理。长期知识记忆是跨会话可复用的信息比如用户的偏好、业务术语定义、常见的查询模式这部分可以存到向量数据库里按需检索。实现的时候不要勉强让模型决定“该删除什么”。工程上可以做成显式的状态对象每一步把关键信息写入状态然后只把状态中的摘要部分拼接到下一次模型调用的上下文里。比如一个问数Agent的执行状态可以写成{ user_intent: 销售趋势分析, filters: {region: 华东, date_range: 2026Q1}, steps: [ {tool: query_sales, status: done, summary: 销售额环比下降12%}, {tool: query_growth_rate, status: pending} ], final_answer_draft: null }每次调用模型前把状态序列化成一个紧凑的JSON片段作为额外上下文。模型不仅能看懂还能基于状态继续规划。这比把所有原始工具输出都塞进上下文要有效得多。2.3 工具调用的准确性与容错设计工具调用是Agent与外部世界交互的通道。现在的模型在生成结构化的工具调用参数上已经比较稳定但依然需要做一层“参数校验”。我习惯在工具调用层加一个独立于模型逻辑的校验器用代码强制校验参数类型、取值范围、必填项。例如模型输出一个“query_sales”工具调用参数是“date_range”字符串但校验器发现这个字符串格式非法就拒绝调用并回传错误信息让我重新生成。这里有个细节错误信息也要写得适合模型阅读。不要返回一堆堆栈信息最好给模型一个人类可读的提示比如“参数date_range格式应为YYYY-MM-DD到YYYY-MM-DD”。模型看到这个提示后通常下一轮就能纠正。容错设计上我会给每个工具设置两个参数超时时间和最大重试次数。比如数据库查询工具超时设置为5秒重试2次外部API调用超时设置10秒重试1次。如果重试后还是失败就标记该步骤失败并让模型决定是否更换方案而不是整条任务直接终止。这比在模型Prompt里写“如果失败就重试”要可靠得多毕竟模型面对具体异常时往往会把事情搞得更复杂。3. 实操过程与核心环节实现从单模型到多智能体协同的演进实战3.1 案例背景企业问数智能体用一个我做过多次的企业问数智能体作为例子。这个系统的核心能力是让用户用自然语言查询企业内部的销售、库存、财务等数据。最初版本是一个单模型Agent直接把用户问题翻译成SQL然后查询数据库返回结果。做了一段时间后问题开始集中爆发用户问“为什么华东区销售额下降了”单模型Agent只会把数据查出来却无法解释“为什么”。数据权限校验复杂不同角色能看的数据范围不一样单模型Agent经常越权生成SQL。涉及多个数据源的关联查询时模型生成的SQL又长又容易错排错成本极高。于是开始重构把单模型Agent拆分成了三个专职Agent加一个协调者。这套架构运行下来整体准确率从不到70%提升到了90%以上而且每个Agent的Prompt都短了很多维护起来也轻松了不少。3.2 多智能体架构设计四个角色划分在这套问数系统里四个角色各有分工入口AgentFront Door负责接收用户的自然语言完成意图识别和需求澄清。它不生成SQL不查询数据只输出一个标准化的“查询意图对象”。协调者AgentOrchestrator不直接调用数据工具而是根据入口Agent输出的查询意图对象决定执行策略。如果是简单的单表查询直接派发给查询Agent如果需要复杂分析则拆解成多个子任务分发并聚合结果。查询AgentQuery Executor负责把查询意图转成最优的SQL并执行。它是数据链路的核心被设计为无状态每次只处理一个查询任务。分析AgentData Analyst负责对查询结果进行洞察分析例如对比、趋势、异常归因等。它不接触原始数据库只接收查询Agent返回的结果集。它们之间的通信没有采用任何重量级消息队列而是通过一个共享的“任务状态存储”来实现简单说就是一张任务表每行记录一个任务的执行状态和结果。Agent之间不直接互相调用而是读写这张表。这样设计的好处是系统天然具备异步性任何一个Agent都可以由多个Worker并发实例运行只要它们读写同一张任务表即可。3.3 关键实现从单Agent改造为多Agent的代码骨架下面给出一个简化但可运行的Python骨架使用的核心库只有FastAPI和一个基础大模型客户端的封装。为方便理解我省略了具体的模型API细节。# agent_framework.py from dataclasses import dataclass, field from typing import Dict, List, Optional dataclass class Task: task_id: str task_type: str # requirement_parse, query, analysis, aggregate input: Dict[str, str] status: str # pending, running, done, failed output: Dict[str, str] field(default_factorydict) parent_id: Optional[str] None children: List[str] field(default_factorylist) class TaskStore: 简化版任务状态存储真实环境可用Redis或数据库 def __init__(self): self._tasks: Dict[str, Task] {} def create_task(self, task_type: str, input: dict, parent_id: Optional[str] None) - str: task_id ftask_{len(self._tasks) 1} task Task(task_idtask_id, task_typetask_type, inputinput, parent_idparent_id) self._tasks[task_id] task return task_id def update_task(self, task_id: str, status: str None, output: dict None): task self._tasks[task_id] if status: task.status status if output: task.output output def get_task(self, task_id: str) - Task: return self._tasks[task_id] def get_pending_tasks(self) - List[Task]: return [t for t in self._tasks.values() if t.status pending]# agents.py class BaseAgent: def __init__(self, model_client): self.model_client model_client def run(self, task: Task) - dict: raise NotImplementedError class EntryAgent(BaseAgent): 入口Agent把用户需求解析成结构化意图 def run(self, task: Task) - dict: user_query task.input[query] prompt f 你是企业数据查询入口请把用户的需求解析成JSON结构。 用户需求{user_query} 输出JSON格式如下 {{intent: sales_query, metrics: [sales], dimensions: [region], filters: {{time_range: ..., ...}}}} 只输出JSON。 result self.model_client.generate(prompt) return {parsed_intent: result} class QueryAgent(BaseAgent): 查询Agent根据意图对象生成并执行SQL def run(self, task: Task) - dict: intent task.input[parsed_intent] sql self.generate_sql(intent) result_data self.execute_sql(sql) return {sql: sql, data: result_data, summary: 查询到12行结果华东区销售额环比下降12%} def generate_sql(self, intent: dict) - str: # 这里省略具体prompt构造逻辑实际会利用意图JSON来生成SQL return SELECT region, SUM(sales) FROM sales_data WHERE time_range2026Q1 GROUP BY region def execute_sql(self, sql: str): # 调用数据库连接执行SQL此处省略 return [{region: 华东, sales_sum: 12345}] class AnalysisAgent(BaseAgent): 分析Agent基于查询结果做归因分析 def run(self, task: Task) - dict: data task.input[query_result] prompt f基于这个销售数据{data}分析华东区销售额环比下降的可能原因。 analysis self.model_client.generate(prompt) return {analysis: analysis} class Coordinator: 协调者负责任务调度 def __init__(self, task_store: TaskStore, agents: Dict[str, BaseAgent]): self.task_store task_store self.agents agents def submit_user_query(self, user_query: str) - str: # 创建入口任务 entry_task_id self.task_store.create_task(requirement_parse, {query: user_query}) self.run_agent(entry, entry_task_id) entry_task self.task_store.get_task(entry_task_id) parsed_intent entry_task.output[parsed_intent] # 创建查询任务 query_task_id self.task_store.create_task(query, {parsed_intent: parsed_intent}) self.run_agent(query, query_task_id) query_task self.task_store.get_task(query_task_id) query_result {query_result: query_task.output[data]} # 创建分析任务 analysis_task_id self.task_store.create_task(analysis, query_result) self.run_agent(analysis, analysis_task_id) analysis_task self.task_store.get_task(analysis_task_id) return analysis_task.output[analysis] def run_agent(self, agent_key: str, task_id: str): task self.task_store.get_task(task_id) # 任务状态置为运行中 self.task_store.update_task(task_id, statusrunning) agent self.agents[agent_key] output agent.run(task) self.task_store.update_task(task_id, statusdone, outputoutput)上面的骨架非常简化但已经体现了多Agent协同的基本思想任务状态存表、Agent无状态执行、协调者统一驱动。实际生产里协调者可以并行派发多个查询子任务也可以用异步任务队列来提升吞吐量。核心在于千万别让Agent之间直接通过函数调用来互相调用一旦Agent多了调用关系会乱成一团。3.4 任务拆分与结果聚合从串行到并行多Agent协同真正的性能提升来自任务级并行。例如用户问“对比2025年和2026年第一季度各区域的销售表现并指出异常区域。”对于这个需求协调者不应该只创建一个查询任务而应该拆成“创建2025年Q1查询任务”和“创建2026年Q1查询任务”两个互不依赖的子任务并行执行。等两个子任务都完成后再交给分析Agent。实现并行其实非常简单只要TaskStore支持并发读写协调者把两个子任务写入待办列表然后启动两个Worker进程或协程各自执行即可。要注意的是状态管理必须加锁或使用数据库事务否则两个Worker同时更新某个共享字段时会互相覆盖。结果聚合阶段最容易忽视的一件事聚合不是简单拼接而是要做“信息合并”。比如两个查询任务分别返回了表格型的结果集分析Agent需要的是一个统一的结构化数据而不是两段文字。我在设计时会让查询Agent输出结构化的JSON结果分析Agent接收JSON数组并额外要求它输出“异常原因可能有1...2...”这样的结构化回答。这样既方便用户阅读也方便后续任务继续引用。3.5 从单模型到多Agent的平滑迁移路径如果你已经有一个跑着的单模型Agent不要一次性推倒重来。我的建议是分三步走。第一步给现有Agent加上“状态对象”。无论内部是否拆分先让系统显式维护执行状态把每一步的工具调用和结果摘要记录下来。这一步不会改动用户可见行为但后续拆分时这些状态就是各个Agent之间传递的数据契约。第二步抽出第一个专用Agent。找一个职责最单一、最容易验证的环节比如“参数标准化Agent”专门负责把用户输入中的日期、金额、地区等实体提取成标准格式。让原来主Agent不再自己处理这些而是先调用这个专用Agent。这样改动面小又能立刻减少主Agent在参数抽取上的压力。第三步逐步迁移到多角色架构。每次只迁移一个职责跑稳了再迁下一个。整个过程可能持续两三个迭代版本但风险可控而且每个阶段都能产出一个可交付的系统。别想着一步到位直接上多Agent编排否则光是Agent之间的交互Bug就能让你怀疑人生。4. 常见问题与排查技巧实录多智能体协同的典型事故4.1 智能体之间死锁或互相等待多Agent系统里最常见也最可怕的问题就是死锁。比如协调者派发了一个“查询任务”然后等待查询Agent的结果但查询Agent在启动之前却要求协调者必须先提供一份“查询权限校验结果”。如果权限校验结果本身又是一个Agent生成的任务而协调者没处理好依赖关系整个流程就会卡死。排查技巧给每个Task加上timeout和依赖列表。在创建子任务时显式声明它依赖哪些父任务或兄弟任务的结果。我习惯用一个小工具体检任务依赖图每次派发任务前先检查“是否所有依赖项都已经完成”。另外在协调者代码里加一个全局超时机制如果整个任务在30秒内没有流转到新状态就强制标记为失败并走人工兜底。这个兜底措施能避免线上“死任务”堆积。4.2 上下文重复导致Token浪费在多Agent架构里很多人会犯一个错误为了让每个Agent都能掌握完整信息会把所有上游输出全部传给下游。比如分析Agent拿到了入口Agent的解析结果、查询Agent的SQL和原始数据、甚至包括中间的错误重试记录整个上下文膨胀到几万Token。在Agent数量少时还勉强能忍一旦有5个以上Agent总Token消耗会直线上升成本控制直接崩盘。我的实践经验是定义清晰的“数据契约”每个Agent只接收它执行任务需要的最少字段输出也只包含核心字段。比如分析Agent只需接收“数据摘要 用户问题”不需要知道SQL长什么样。这需要你在设计Task的input/output结构时反复推敲多做减法。4.3 同一个子任务被多个Worker重复执行当多个Worker并行消费任务表时如果“领取任务”和“更新任务状态”之间没有原子性保证两个Worker可能同时抢到同一个任务造成重复执行。对于查询数据库这种副作用操作重复执行会导致不必要的资源浪费对于写操作类的任务甚至会产生脏数据。解决方法很简单任务表加一个状态字段并且更新时带上条件“WHERE status pending”。在数据库层面执行类似UPDATE task SET status running WHERE task_id ... AND status pending 这样的原子操作。如果更新影响行数为0说明任务已被其他Worker领取当前Worker直接跳过即可。这套机制和分布式任务队列的原理完全一致不要以为系统小就不需要。4.4 Agent输出格式不规范导致下游解析崩溃模型输出是概率性的哪怕你Prompt里写了“只输出JSON”它也有可能多出一行解释或者一个Markdown代码块。下游Agent拿到解析不了的结果就会报错。这个问题在单Agent里也有但多Agent架构会把问题放大因为每个环节都依赖前面的输出格式。我一般会做两层防护。第一层是“输出清洗器”在Agent结果返回后用代码尝试提取JSON或关键字段如果提取失败就重试一次重试时额外给模型提示“你上次的回复不完整请只输出JSON”。第二层是“字段兜底”设计的输出结构尽量带有默认值例如解析不到日期范围时默认用最近30天避免因为一个字段缺失导致整个任务失败。这两层防护加下来端到端的成功率能提高好几个百分点。4.5 反馈循环导致的逻辑失控多Agent协同还有一个隐蔽问题A Agent修改了某个状态B Agent基于修改后的状态做了一个操作操作结果又反过来触发A Agent再做一次修改形成一个无限循环。这在高度自治的多Agent系统里尤其常见比如“客服Agent”和“退款Agent”之间可能因为退款单状态反复变更而陷入拉锯。控制方法是给所有Agent操作加上“单调性约束”不允许Agent将一个任务状态从终态改回中间态。例如查询任务一旦“done”就不允许被其他Agent重新置为“pending”。再一个方法是为每次Agent操作记录操作日志并设置最大调用次数比如同一任务最多允许被改写5次超过则人工介入。不依赖模型“自觉”而是靠工程机制兜底这是所有Agent架构设计的底层共识。5. 工具选型与模型策略别被新框架绑架5.1 Agent框架选型轻量优先还是全家桶优先2026年前后市面上已经出现了很多Agent框架有偏向Web自动化的有偏向数据分析和代码执行的也有面向企业流程编排的。我在选型上有一个坚持原则能不用框架就不用框架就算用框架也只把它当工具库不让它接管核心控制流。原因是Agent项目的核心价值在业务逻辑和状态设计而不在框架本身。框架封装越重你排查问题就越困难。尤其是一些框架自带复杂的记忆系统或Agent间通信机制一旦出现诡异行为你根本不知道是自己代码的问题还是框架内部逻辑的问题。我见过不少团队被框架的“高级特性”带偏最后连最基础的调试日志都打不干净。如果一定要用框架我建议选择模块化程度高的让Agent的实现类可以独立测试、独立运行而不是必须依赖全家桶环境。另外框架的版本升级要跟上核心版本锁定后不要轻易升级Agent框架的破坏性变更非常频繁。5.2 模型选型不同Agent用不同模型在2026年模型能力已经呈现出明显的分层趋势。对于入口Agent这种需要大量语义理解、意图识别、多轮对话的任务适合用能力最强、上下文足够长的旗舰模型。对于查询Agent这种需要精确生成SQL、处理严格结构化格式的任务适合用代码能力突出且输出稳定性高的模型不一定非要用最贵的。对于分析Agent则适合有较强推理能力的模型。这种“分级用模”的策略能在成本和效果之间取得较好的平衡。入口Agent调用频率相对低但质量要求高用旗舰模型没问题查询Agent调用频率极高如果用旗舰模型账单会非常吓人而这种重复性较高的任务一个中等规模的模型加上强校验逻辑完全足够。我实测下来的一个经验是查询Agent的SQL准确率用旗舰模型和中等模型差别可能只有5%但成本差了5到10倍因此分级策略的收益非常可观。5.3 可观测性多Agent架构的命门单Agent只有一个黑盒出了问题无非就是Prompt和上下文的问题。多Agent架构是一群黑盒互相协作出了问题你连是哪个环节坏的都难定位。因此可观测性不是可选项而是必须项。我的做法是给每个Agent分配一个全局唯一的执行trace_id从入口Agent开始一路透传到所有子任务。每个Agent执行前后都要打日志记录输入、输出、耗时的摘要。状态存储里的每一步变更也要留痕。除了日志还要有可视化工具。虽然不让用Mermaid但可以用现成的时序图工具或者自建一个简单的Web界面把任务流转过程渲染出来。没有这个监控界面多Agent系统上线后就是摸黑开车。实际操作中我甚至会给Agent的关键分支打点比如“查询Agent选择了走SQL生成路径”和“查询Agent选择了走假设分析路径”分别统计一次。通过成功率监控你能快速发现某个特定分支出了问题进而定位到对应的Agent和Prompt。6. 未来演进重要的不是架构是边界感多Agent协同在2026年会继续向成熟方向演进但我个人并不迷信“Agent越多越好”的激进思路。架构设计的核心始终是边界能力的边界、职责的边界、状态的边界、模型的边界。一个设计良好的多Agent系统应该像一支成熟的团队每个人都知道自己该做什么、不该做什么遇到问题知道该找谁、该用什么方式反馈。与此相对一个设计糟糕的多Agent系统就像把一堆人扔进一个没有流程的房间每个人都拿着喇叭说话最后谁也听不清谁。再分享一个我个人的小习惯在每个Agent的System Prompt里除了告诉它“你要做什么”还必须写清楚“你不需要做什么”。很多模型在开放式任务里会下意识地越权尝试解决自己职责范围外的问题。比如查询Agent看到数据异常忍不住开始写分析建议而分析Agent也在做同样的事两边重复输出结果白白浪费Token、增加冲突。给Agent加上职责边界约束之后这类问题会明显减少。如果你正准备着手搭建或者重构自己的AI Agent系统建议先拿笔在纸上画出所有Agent角色和你希望它们之间流转的数据对象。不要急着写代码先把“谁产生什么”“谁消费什么”“谁修改什么状态”搞清楚。这份边界清单比任何框架都更能帮你避坑。等你跑通了一版再回顾这篇文章里提到的状态管理、任务并发和可观测性你会发现自己已经跨过了从单模型到多智能体协同最难的那道坎。