标签： 架构设计

ai-workbench 的工作流引擎把任务生命周期拆成三个角色，每个角色有独立的 system prompt，甚至可以用不同的模型配置： 三个角色的职责在 中严格界定： Planner：只做拆解，输出带验收标准的 JSON 计划，不执行任何命令 Specialist：只执行当前这一步，产出交付物，可以运行 shell 命令…阅读全文 →

直觉做法：状态图 + 条件边 如果你熟悉多智能体编排框架，可能会想到 LangGraph 的 StateGraph。它用显式的条件边来控制流程分支： 每次流程分支都需要手动编写判断逻辑——Evaluator 通过后走哪条边、有问题时走哪条边，代码里到处是条件判断。 实际做法：事件驱动 + @step 装饰器 llamaindex-pse …阅读全文 →

为什么需要显式的状态机？ 多 Agent 框架有两种哲学：隐式流程和显式状态机。 CrewAI 的 流程属于前者——Agent 按顺序执行，但你无法在运行时查看中间状态、无法在某个节点插入自定义逻辑、更无法精确控制重试路径。当任务变复杂，黑…阅读全文 →

多 Agent 系统的信任危机 你有没有遇到过这种情况：让一个 LLM 审核另一个 LLM 的输出？ 假设你搭建了一个三角色文章生成管道：Planner 负责规划结构，Specialist 负责撰写内容，Evaluator 负责审核质量。听起来很完美，对吧？但当你仔细审视 Evaluator 的工作时，会发现一个根本性的矛盾——Evalu…阅读全文 →

从单一检索到混合策略 在传统 RAG 系统中，检索环节通常依赖向量相似度搜索。这种方式擅长捕捉语义相似性，但当用户查询包含精确术语、专有名词或特定格式时，纯语义检索往往会失效。 你有没有遇到过这样的场景：查询"IRR 计算公式"，系统却返回了大量讨论"投资回报率概念"的文档，而真正包含公式细节的文档反而被排在后面？这是因为向量嵌入在编码时…阅读全文 →

2.1 设计决策 1：Markdown 作为状态机与控制流 直觉会怎么做：使用数据库或复杂的 JSON 结构来管理任务状态，在代码中硬编码流程逻辑。 实际怎么做的：Agentic Souls 使用一系列结构化的 Markdown 文件作为唯一的真相来源。每个文件代表工作流的一个阶段，文件的创建和更新即为状态迁移。 根…阅读全文 →

2.1 设计决策 1：用 替代 Function Calling 实现 PSE 状态机 直觉会怎么做：为 Planner、Specialist、Evaluator 分别定义工具函数，通过 LLM 的 Function Calling 来选择下一步动作，手动维护状态转移图。 实际怎么做的：直接使用 AutoGen 的 顺序…阅读全文 →