1. 项目缘起与核心定位五周前我决定做一件有点“疯狂”的事在完全公开的状态下从零开始构建一个多智能体框架。没有周密的商业计划没有封闭的团队只有GitHub上一个个实时提交的Commit和一篇篇记录思考的文档。这与其说是一个项目不如说是一场持续了35天的、面向所有人的“直播开发”。现在这段旅程告一段落框架的核心骨架已经成型是时候回过头来把这段充满代码、咖啡和意外发现的经历掰开揉碎了讲给你听。这个框架的目标很明确降低复杂多智能体系统的构建门槛。我们见过太多关于AI智能体协同工作的炫酷演示但当你真正想用它来解决一个稍微复杂点的实际问题时——比如自动处理一份结构混乱的客户需求文档并协调设计、开发、测试多个环节的模拟——你会发现现有的工具要么过于笨重像个需要专业司机才能驾驭的巨型卡车要么过于玩具化连基本的任务拆解和结果汇总都做不好。我的目标就是造一辆“家用SUV”足够强大能应对复杂路况又足够易用让有驾照的人都能开上路。为什么选择完全公开这背后有几个很实际的考量。首先透明是最高效的反馈机制。每一行架构设计代码每一个接口定义都暴露在同行眼前。这种压力迫使你必须思考得更深设计得更优雅因为你知道随时可能有高手路过留下一句“这里的设计是不是有点问题”。其次它本身就是一个绝佳的“用例”。一个关于“如何构建协作系统”的项目其开发过程本身就需要高度的内部协作虽然目前主要是我自己和任务管理这让我能第一时间在自己的“狗食”里尝出味道。最后我希望它能成为一个活的案例库。框架不是凭空设计出来的而是伴随着一个个具体应用场景我们称之为“剧本”长出来的这些场景代码和解决过程本身就是最宝贵的文档。2. 核心设计哲学从“管道”到“片场”在深入代码之前我想先聊聊这个框架的“灵魂”也就是它的设计哲学。这五周最大的认知迭代就是从传统的“数据处理管道”思维转向了“电影片场”思维。2.1 传统管道的局限性大多数早期的多智能体框架或者广义的任务编排系统都深受“管道”或“工作流”模型的影响。任务像流水线上的零件从一个“工人”智能体手里传到下一个每个工人只负责一道工序。这种模型清晰、可控但僵化。它隐含了一个假设任务路径是预先可知的、线性的。然而真实世界的问题尤其是需要创造性或复杂决策的问题其解决路径往往是探索性的、动态分叉的。比如让智能体分析一篇技术博客并给出实现方案它可能需要先调研背景发现知识缺口后去搜索资料然后根据资料质量决定是继续深入还是换方向最后再生成方案。这是一个典型的动态决策树而非固定流水线。2.2 “片场”模型的引入“片场”是我能找到的最贴切的比喻。在这个模型里导演 这是框架的核心调度器。它不关心具体某个镜头怎么拍而是手握“剧本”高层任务目标负责宏观协调。它决定什么时候该哪个“演员”上场什么时候需要“道具组”支援以及如何根据“拍摄”执行情况调整后续计划。演员 这就是各个智能体。每个演员有自己明确的戏路能力边界比如有的擅长分析文本有的擅长生成代码有的擅长检索信息。导演根据剧本情节任务阶段挑选合适的演员上场。剧本 这是用户定义的高层目标和工作流约束。它不像流水线的详细步骤而更像一个故事大纲规定了起承转合和关键情节点但具体怎么演给演员留出了发挥空间。场记 这是框架的上下文管理与记忆系统。它负责记录每个镜头的拍摄情况任务历史确保演员不会忘记之前的剧情对话历史并且能把道具中间数据准确地传递给需要的人。这个模型的优势在于动态性与责任感分离。导演负责动态决策和协调演员专注于发挥专业能力场记确保信息不丢失。框架要做的就是提供一套好用的“制片工具”让搭建这样一个“片场”变得简单。2.3 技术架构的顶层设计基于“片场”模型框架的顶层分为了清晰的三层编排层这是“导演”所在的地方。它提供定义“剧本”的领域特定语言DSL。用户可以用近乎自然语言的方式描述“先让分析员理解需求然后让架构师给出设计期间如果需要查资料就让研究员去搜索最后让工程师实现。” 框架会将其编译成可执行的任务图。这里的关键是支持条件分支、循环和动态任务注入。比如“如果架构师认为需求不明确则先让需求澄清员介入”。智能体层这是“演员”的休息室和化妆间。框架提供智能体的基类定义标准的“试镜”接口能力描述和“表演”接口执行方法。一个智能体的核心包括身份与指令 它是谁它的背景、性格、沟通风格如何这决定了它与其他智能体交互的“人设”。能力工具集 它能做什么是调用大语言模型API还是操作某个软件或是使用特定的计算函数框架提供统一的工具注册和调用机制。交互协议 它如何与其他智能体或导演沟通框架内置了基于消息队列的发布-订阅模型智能体可以监听特定主题的事件如“需求分析完成”并做出反应。运行时层这是“片场”本身包含“场记”的工作。它管理着任务队列、上下文存储、通信总线和观察性组件。所有智能体的对话、工具调用结果、任务状态变更都被结构化地记录下来形成一个完整的“拍摄日志”。这不仅用于调试更重要的是为后续的任务执行提供丰富的上下文实现某种形式的“经验”积累。注意这里有一个重要的设计取舍我们没有采用某些框架中“智能体自动协商任务”的完全去中心化模式。虽然那听起来更“智能”但在复杂任务中极易陷入混乱的讨论或死锁。保留一个轻量级的“导演”角色进行协调在效率和控制力上取得了更好的平衡。导演可以很“笨”只需要基于简单规则如任务状态做调度但这根“定海神针”是必须的。3. 关键组件深度剖析与实现有了顶层设计我们来看看几个关键组件是如何从图纸变成代码的。这部分会涉及一些具体的技术选择我会解释为什么这么做以及踩过哪些坑。3.1 智能体基类不止是LLM的包装器很多人认为智能体就是给大语言模型套个壳加个“你是XX专家”的提示词。在这个框架里智能体被设计成一个更具自主性的实体。class Agent: def __init__(self, name, role, instructions, toolsNone, memoryNone): self.name name self.role role # 角色如“资深软件架构师” self.instructions instructions # 核心指令和行为约束 self.tools tools or [] # 可调用的工具列表 self.memory memory # 个体记忆用于存储私有会话历史 self.inbox [] # 消息收件箱 self.state idle # 状态idle, thinking, acting, waiting async def perceive(self, message): 接收消息更新状态和记忆 self.inbox.append(message) self.memory.add(message) if self.memory else None self.state thinking async def think_and_act(self, context): 核心决策循环思考并采取行动 # 1. 综合收件箱消息和上下文 prompt self._construct_prompt(context) # 2. 可能调用LLM进行决策 decision await self.llm_client.decide(prompt) # 3. 决策可能是发送消息、调用工具、或更改自身状态 if decision.action send_message: await self._send(decision.target, decision.content) elif decision.action use_tool: result await self._use_tool(decision.tool_name, decision.parameters) # 工具结果可能触发新消息或状态更新 await self._handle_tool_result(result) self.state acting实现要点与避坑异步是生命线 所有智能体的perceive和think_and_act都必须是异步的。同步调用会彻底阻塞整个系统当一个智能体在“思考”等待LLM响应时其他智能体应该能继续工作。我们使用了asyncio作为并发基础。状态管理至关重要 简单的idle/thinking/acting状态机配合消息收件箱是避免智能体“胡言乱语”或重复行动的关键。只有在idle状态且收件箱有消息时才会触发think_and_act。工具调用的标准化 所有工具都遵循统一的接口async def run(self, input: Dict) - Dict。框架提供一个工具注册中心智能体通过名称查找和调用。这允许热插拔工具比如把“谷歌搜索”换成“内部知识库检索”。记忆的分层设计 我们区分了对话记忆智能体私有的聊天历史、任务记忆当前任务相关的关键信息和长期记忆可选的向量存储用于跨任务知识留存。默认只使用前两者以控制复杂度。实操心得初期我曾让智能体直接访问全局上下文结果导致了难以调试的竞态条件和状态污染。后来严格采用了消息传递机制智能体只能通过收发的消息来感知世界这大大提高了系统的可预测性和可调试性。这就像在片场演员不应该直接去改剧本或指挥灯光师而应该通过对讲机与导演沟通。3.2 编排引擎将剧本编译成任务图编排层是框架的“大脑”。它的输入是用户用YAML或Python DSL写的“剧本”输出是一个可执行的任务图。一个简单的剧本示例name: 技术方案设计流程 actors: - name: analyst type: TextAnalysisAgent config: { expertise: 需求分析 } - name: architect type: CodingAgent config: { expertise: 系统架构 } - name: researcher type: WebSearchAgent config: { max_results: 5 } script: - scene: 分析需求 actor: analyst input: {{用户输入}} triggers: - event: analysis_complete next: 设计架构 - scene: 设计架构 actor: architect input: 基于分析结果{{analyst.output}}设计系统架构。 triggers: - event: design_complete next: 结束 - event: need_more_info action: 启动研究 next: 补充研究 - scene: 补充研究 actor: researcher input: 为架构设计查询关于{{architect.question}}的资料。 triggers: - event: research_complete next: 设计架构 # 跳回上一步继续设计引擎的工作流程解析与验证 检查剧本语法确认所有引用的智能体都已注册触发器事件定义正确。编译成任务图 将剧本中的scene转换为图节点triggers转换为有向边。关键点在于处理条件边如event: need_more_info和循环边如从“补充研究”跳回“设计架构”。实例化与注入 根据剧本中的actor配置从智能体池中实例化具体的智能体对象并将它们“注入”到对应的任务节点中。生成执行计划 任务图本身是静态的但执行计划是动态生成的。引擎会从一个或多个起始节点开始根据节点执行结果和触发器条件决定下一步激活哪个节点。技术挑战与解决方案动态依赖解析 在“设计架构”节点中input字段引用了{{analyst.output}}。引擎必须在执行到该节点时能够从上下文存储中检索到analyst这个智能体在之前任务中产生的输出。我们实现了一个简单的模板渲染器支持上下文变量的插值。循环与终止条件 像上面例子中的循环如果不加控制可能导致无限循环。我们在每个节点设置了最大重试次数并在引擎层面监控整个任务的执行时长和循环检测。并发与资源限制 多个任务节点可能同时满足执行条件例如在并行处理分支中。引擎需要管理一个工作池控制同时活跃的智能体数量避免资源特别是昂贵的LLM API调用耗尽。3.3 上下文管理与通信总线这是框架的“中枢神经系统”也是最容易成为性能瓶颈的地方。它的设计目标是高效、一致、可观测。上下文存储我们没有使用复杂的图数据库而是采用了一个分层的、内存优先的存储结构。会话级存储 整个任务会话的全局变量键值对形式用于存储analyst.output这类中间结果。智能体级存储 每个智能体独立的对话历史和工作记忆。这部分通常以列表形式存储消息对象。工具调用记录 所有工具调用的输入、输出、状态和时间戳用于调试和审计。所有存储操作都通过一个统一的ContextManager接口进行它背后可以根据配置决定是纯内存存储还是持久化到Redis或数据库。默认使用内存存储因为对于大多数短期运行的智能体任务来说这已经足够且速度最快。通信总线我们实现了一个基于主题的轻量级消息总线。智能体不直接相互调用而是向总线发布消息。class MessageBus: async def publish(self, topic: str, message: Message): # 将消息放入对应主题的队列 # 并通知所有订阅了该主题的监听器通常是智能体或引擎 pass def subscribe(self, topic: str, callback: Callable): # 注册一个对特定主题消息的回调函数 pass例如当analyst完成工作时它会发布一条主题为task.analysis.complete的消息内容包含其输出。编排引擎订阅了这个主题收到消息后就会触发“设计架构”任务节点的执行。这种松耦合设计的好处是巨大的可扩展性 可以轻松加入新的“监听者”比如一个日志智能体订阅所有消息用于生成执行报告。可测试性 可以模拟消息输入来测试单个智能体或任务节点无需启动整个系统。灵活性 智能体不需要知道消息的最终消费者是谁实现了生产者与消费者的解耦。踩坑实录第一版我用了同步的消息队列当某个智能体处理消息较慢时整个总线会被阻塞。后来全面切换到asyncio.Queue每个主题一个队列并由独立的异步任务消费彻底解决了阻塞问题。另一个坑是消息格式不统一导致订阅者解析困难。后来强制规定所有消息都必须是一个包含type、sender、content、timestamp的标准Message对象。4. 一个端到端的实战剧本从需求到代码理论说了这么多我们来看一个具体的、可运行的例子。假设我们要实现这样一个自动化任务“请分析这个关于用户登录功能的简短需求描述并生成一个Python Flask API的初步实现代码。”4.1 剧本定义我们定义三个智能体需求分析师 擅长理解模糊需求提出澄清问题并输出结构化需求。API设计师 根据结构化需求设计RESTful API端点、请求/响应模型。Python工程师 根据API设计编写具体的Flask应用代码。对应的剧本YAML如下name: 需求到Flask代码生成 actors: - name: req_analyst type: AnalystAgent config: { tone: 严谨, output_format: markdown } - name: api_designer type: DesignerAgent config: { framework: flask, style: RESTful } - name: python_dev type: DeveloperAgent config: { language: python, framework: flask } script: - scene: 需求澄清与分析 actor: req_analyst input: | 原始需求{{user_input}} 请你分析该需求明确以下要点 1. 核心功能点 2. 必要的输入输出 3. 潜在的业务规则如密码强度、登录失败处理 4. 任何模糊需要假设的点 请以结构化格式输出。 triggers: - event: analysis_submitted next: API设计 - scene: API设计 actor: api_designer input: | 根据以下需求分析进行API设计 {{req_analyst.output}} 请给出 1. 端点列表路径、方法 2. 每个端点的请求体/参数说明 3. 响应体格式 4. 可能的错误码 triggers: - event: design_submitted next: 代码实现 - scene: 代码实现 actor: python_dev input: | 根据以下API设计实现Flask应用 {{api_designer.output}} 要求 1. 代码完整可直接运行假设有虚拟的数据库层 2. 包含必要的导入和错误处理 3. 代码风格良好有简要注释 triggers: - event: code_submitted next: END # 任务结束4.2 运行与交互过程当用户输入“我需要一个用户登录功能包含邮箱密码登录和JWT令牌返回”后框架会这样运行引擎启动 解析剧本创建任务图实例化三个智能体。场景一执行 “需求分析师”智能体被激活。它接收用户输入调用其背后的LLM如GPT-4进行分析。它可能会“思考”“需求比较简短我需要明确是否包含注册功能JWT的刷新机制如何登录失败是否要锁定账户” 最终它输出一份结构化的Markdown文档包含明确的功能点、假设例如“假设已有用户数据库”并发布analysis_submitted事件。场景二触发 编排引擎监听到事件从上下文中取出req_analyst.output将其渲染到API设计节点的输入模板中然后激活“API设计师”智能体。该智能体根据结构化的需求设计出如POST /auth/login、POST /auth/refresh等端点并详细定义JSON格式。完成后发布design_submitted事件。场景三触发与结束 “Python工程师”智能体被激活它接收API设计文档开始编写Flask代码。它会生成包含路由、JWT工具函数、模拟用户验证逻辑的完整app.py文件。发布code_submitted事件后引擎判断任务结束汇总最终输出即生成的代码返回给用户。整个过程中用户无需干预。智能体之间通过消息总线传递结构化的输出编排引擎像导演一样确保流程按剧本推进。如果“API设计师”在设计中认为需求分析有缺失它可以向总线发布一个request_clarification事件我们甚至可以在剧本中预先定义让引擎此时暂停并通知用户介入实现人机协同。4.3 效果评估与输出示例运行上述剧本最终“Python工程师”可能生成如下代码节选from flask import Flask, request, jsonify from flask_jwt_extended import JWTManager, create_access_token, jwt_required, get_jwt_identity import datetime app Flask(__name__) app.config[JWT_SECRET_KEY] your-secret-key-change-this # 生产环境应从环境变量读取 jwt JWTManager(app) # 模拟用户数据库 users { userexample.com: {password: hashed_password_123, id: 1} } app.route(/auth/login, methods[POST]) def login(): data request.get_json() email data.get(email) password data.get(password) # 此处应为前端传输的哈希后密码 user users.get(email) if not user or user[password] ! password: # 简化对比实际应使用密码哈希验证 return jsonify({msg: 邮箱或密码错误}), 401 # 创建JWT令牌 access_token create_access_token(identityemail, expires_deltadatetime.timedelta(hours1)) return jsonify(access_tokenaccess_token), 200 app.route(/auth/refresh, methods[POST]) jwt_required(refreshTrue) # 假设使用刷新令牌 def refresh(): current_user get_jwt_identity() new_token create_access_token(identitycurrent_user, expires_deltadatetime.timedelta(hours1)) return jsonify(access_tokennew_token), 200 if __name__ __main__: app.run(debugTrue)这个代码虽然简单但结构清晰包含了错误处理和基本的安全假设注释是一个很好的起点。更重要的是整个生成过程是透明、可追溯的。你可以查看“需求分析师”输出的结构化文档理解代码是如何一步步被推导出来的。5. 开发旅程中的典型问题与排查心法公开构建的这五周几乎每天都会遇到新问题。我把最常见、最棘手的几个问题及其解决方法记录下来希望能帮你绕过这些坑。5.1 智能体“卡住”或陷入循环现象 任务执行到某个节点后停滞不前或者几个智能体来回发送类似的消息无法推进。根因分析触发器事件未正确触发或监听 智能体完成了工作但发布的事件主题与剧本中triggers里定义的不匹配。输入依赖未满足 某个节点的输入模板中引用了{{agent.output}}但该agent的输出在上下文中不存在或为None。智能体决策逻辑缺陷 智能体的think_and_act逻辑陷入局部循环比如一直问同一个问题。排查步骤检查运行时日志 框架的通信总线会记录所有消息。首先查看目标智能体是否发布了完成事件。如果没有说明它可能还在“思考”或遇到了错误。审查上下文状态 在任务停滞时手动导出上下文存储的内容检查被依赖的中间输出是否存在且格式正确。启用智能体“思维”日志 在智能体调用LLM的决策环节将其构造的提示词和得到的响应记录下来。这能最直观地看到智能体“在想什么”。很多时候问题出在提示词工程上导致LLM无法做出有效的下一步决策。简化与回退 如果问题复杂尝试将剧本简化到只剩问题节点和它的前后节点甚至单独测试该智能体。逐步添加复杂度定位问题边界。我的经验为编排引擎和每个智能体设置详细的日志级别DEBUG, INFO, WARN, ERROR是性价比最高的调试投资。我使用structlog库可以非常方便地输出结构化的JSON日志包含会话ID、智能体名、消息ID等用ELK或直接grep都能快速定位问题。5.2 上下文膨胀与性能下降现象 任务运行时间越长速度越慢特别是涉及多轮对话的复杂剧本。根因分析 所有消息和历史都被无差别地存入上下文每次智能体决策时其完整的对话历史都被拼接到提示词中导致提示词越来越长LLM API调用延迟和成本激增。解决方案记忆摘要 实现一个MemorySummarizer组件。对于超过一定轮次的对话不再传递原始消息而是由另一个“总结者”智能体或一个简单的文本摘要函数生成一段摘要。例如将十轮关于技术选型的讨论总结为“智能体A和B最终决定使用Redis作为缓存原因是读写性能高和数据结构丰富”。分层记忆策略 区分“工作记忆”和“长期记忆”。工作记忆只保留最近N轮对话或与本阶段任务强相关的信息使用向量数据库存储长期记忆智能体在需要时通过语义搜索召回相关记忆而不是全量加载。上下文窗口管理 在构造提示词时动态计算token数量如果超过模型上限如GPT-4的8K或32K则优先丢弃最早、或通过相关性评分认为最不重要的历史消息。我目前的策略是摘要为主搜索为辅。对于大多数顺序执行的剧本前一个智能体的输出摘要就是后一个智能体最重要的上下文完整的对话历史更多用于事后审计。这需要在信息丢失和性能之间取得平衡。5.3 工具调用的错误处理与重试现象 智能体调用一个外部工具如网络搜索、数据库查询时失败导致整个任务链中断。根因分析 网络超时、API限流、临时性错误、工具返回非预期格式。解决方案标准化错误响应 所有工具必须捕获异常并返回一个统一格式的错误对象例如{“success”: false, “error”: “Timeout”, “detail”: “...”}而不是抛出异常导致智能体进程崩溃。智能体层面的重试逻辑 在智能体的_use_tool方法中对可重试的错误如网络超时实现简单的指数退避重试。编排引擎的容错 在剧本定义中允许为每个scene节点配置on_failure策略。例如scene: 调用搜索API actor: researcher on_failure: retry: 2 # 重试2次 fallback_scene: 使用备用搜索源 # 重试失败后执行备用场景 or: fail_fast # 或直接失败终止任务工具结果的验证与清洗 对于工具返回的数据在传递给智能体之前可以有一层简单的验证或清洗逻辑比如确保JSON格式正确截断过长的文本等。一个具体的工具类实现示例class WebSearchTool(BaseTool): name web_search description 使用搜索引擎查询信息 async def run(self, input: Dict) - Dict: query input.get(query) if not query: return {success: False, error: Missing query parameter} max_retries 3 for attempt in range(max_retries): try: # 模拟搜索调用 result await self._call_search_api(query) # 清洗结果 cleaned_result self._clean_result(result) return {success: True, data: cleaned_result} except TimeoutError as e: if attempt max_retries - 1: return {success: False, error: Timeout after retries, detail: str(e)} await asyncio.sleep(2 ** attempt) # 指数退避 except Exception as e: # 其他不可重试错误 return {success: False, error: Search failed, detail: str(e)} return {success: False, error: Unexpected error}5.4 多智能体协作中的“共识困境”现象 在需要多个智能体共同讨论达成一致的场景中如设计方案评审讨论容易发散难以收敛。根因分析 LLM驱动的智能体有时会过于“坚持己见”或者在开放性讨论中不断提出新观点导致讨论无法结束。解决方案引入“主持人”角色 设计一个专用的ModeratorAgent它的指令是控制讨论流程。例如“你现在是技术讨论的主持人。你的目标是引导分析师、架构师和工程师在3轮讨论内就数据库选型达成一致。每轮请指定一个发言人并总结当前共识和分歧点。”结构化讨论协议 强制规定讨论步骤。例如第一轮各自陈述观点第二轮针对分歧点进行辩论第三轮进行投票或由主持人裁决。设置明确的停止条件 在剧本中定义讨论结束的条件如“当主持人发布consensus_reached事件”或“讨论达到5轮后自动进入投票环节”。利用元认知提示 在给智能体的提示词中加入元认知指令如“请评估当前讨论是否已足够深入如果主要观点已充分表达请建议进入决策阶段。”在实践中对于需要创造性发散的任务可以放宽收敛要求对于需要明确决策的任务则必须引入强力的结构化流程或主持人角色。没有一种方法适用于所有场景关键是根据剧本目标来设计交互模式。6. 框架的边界、局限与未来可能经过五周的密集开发这个框架已经能够处理许多有趣的多步骤任务。但它远非万能清楚地认识到它的边界比吹嘘它的能力更重要。当前的局限“智能”的边界在于提示词与流程设计 框架本身不产生智能它只是协调者。智能体的表现严重依赖于其背后的LLM能力和精心设计的提示词。一个糟糕的提示词即使有再好的框架也产不出好结果。复杂状态管理的挑战 对于涉及数十个步骤、有大量分支合并的超级复杂流程当前YAML剧本的定义方式会变得冗长且难以维护。需要探索更高级的视觉化编排工具或真正的编程接口如Python SDK。实时性与资源消耗 每个智能体的“思考”都意味着一次LLM API调用在复杂流程中成本和延迟会累积。这限制了其在超低延迟或极高并发场景下的应用。缺乏真正的“学习”能力 框架会记录历史但不会基于历史数据自动优化智能体的行为或剧本流程。每一次运行都是相对独立的。它最适合的场景是什么原型验证与头脑风暴 快速将一个新想法拆解成多智能体协作流程看看能碰撞出什么火花。标准化、可重复的复杂任务 如每周的市场报告生成、代码审查辅助、客户支持工单的初步分类与路由。教育与研究 作为研究多智能体系统交互、社会性AI的沙盒环境。未来的可能性智能体“技能市场” 建立一个共享库用户可以上传/下载配置好的智能体包括其指令、工具集像乐高一样组合使用。剧本的进化与优化 引入强化学习或进化算法让框架能自动运行A/B测试根据任务完成质量需人工或自动评分来调整剧本流程或智能体指令。更强大的人类协同 目前的人类介入点还比较生硬主要是通过事件触发。可以设计更流畅的“人机混合”模式比如人类可以随时以“超级智能体”的身份加入对话修改中间结果或给智能体提供实时指导。底层模型多元化 支持无缝切换不同的LLM后端OpenAI, Anthropic 开源模型等甚至让不同的智能体使用不同的模型以平衡成本与能力。这五周的公开构建最大的收获不是这几千行代码而是一种构建复杂系统的新思维方式。它让我更深刻地理解到将大问题分解成小角色通过清晰的协议让它们协同工作这种模式不仅适用于AI也适用于软件架构和团队管理。代码仓库会继续更新但这段“旅程”本身以及其中关于设计、调试和协作的思考或许才是最有价值的部分。如果你也对用代码“导演”一场AI智能体的演出感兴趣不妨一起加入下一个剧本或许可以由你来写。
