独立开发3：Agent智能路由能实现吗 在上面这篇文档中，我们尝试对独立开发2：less intelligence，more structure进行改造升级，将以人为智能路由中心的方案改为塑造一个智能agent作为路由，实现整个系统的升级。
以下是一个正式的项目说明，对应的文档（架构以及agent的prompt）都会放到github仓库，如果想复用也很简单，将文件夹复制下来放到自己的项目根目录下就行。需要agent的可以单独将agent放到对应的模型文件夹，比如.claude，但经过尝试我并不建议全部使用agent智能路由，理由在文章最后说明。
一套人机协作的vibecoding框架
本项目是一套完整、开源的软件开发框架和协作协议。它旨在解决在复杂项目中，人类开发者与大型语言模型（LLM）之间协作的混乱无序问题。
我们的核心目标是：通过将文档作为项目唯一的状态源，将AI Agent角色化、专业化，以及将人类定义为最终的战略决策者，构建一个可交互、可迭代、高度结构化的智能开发系统。
认知基石 (The Cognitive Foundation)
人（操作员）：系统的战略家 (The Operator: The Strategist)
在本系统中，人的角色不再是事无巨细的“代码保姆”，而是运筹帷幄的“项目战略家”。
- 定义初始框架：创建项目完整的目录结构和所有核心文档的空文件，为AI团队铺好“战场”。
- 提供战略输入：通过“外部Agent”或手动方式，提供项目最初的战略蓝图，如
prd.md,structure.md等。 - 下达高阶指令：向AI团队下达明确的、面向目标的战略指令，如“规划V1版本”或“开发用户认证功能”。
- 最终审批：对
任务编排Agent提交的行动方案进行审查和批准，确保AI的战术规划符合自己的战略意图。
AI团队：高度协同的专家执行者 (The AI Team: The Executors)
我们摒弃了使用单一、通用AI的混沌模式，转而构建了一个由“总指挥”和“专业工匠”组成的AI团队。
- 任务编排Agent (TOA) - 总指挥:
- 它是整个AI团队的大脑和入口。它从不执行具体任务，只负责理解指令、制定计划、协调团队、监督进程。
- 它的所有智慧都来自于对两个文件的理解：
agents.md（它知道团队里有谁、他们擅长什么）和docs_index.md（它知道项目的所有信息都在哪里）。 - 它拥有一个包含多种预设场景的工作流库，能够根据操作员的指令，智能地选择并执行最合适的行动方案。
- 专业Agents - 工匠团队:
- 这是一个由多个拥有不同角色的AI组成的团队，其成员和职责在
agents.md中定义。 架构师Agent: 技术蓝图的绘制者和维护者。产品经理Agent: 用户需求的守护者。前端/后端工程专家Agent: 高质量代码的实现者。测试人员Agent: 产品质量的捍卫者。项目管理员Agent: 项目知识和历史的记录者。
文档：项目的唯一真实状态源 (The Documents: The Single Source of Truth)
在本系统中，代码只是项目状态的一部分，而完整的、唯一的、可信的真实状态，由Core_documents目录下的所有文档共同定义。
- 万物皆文档: 从需求（
prd.md）、架构（structure.md），到API定义（service.md）、测试用例（Test_instances/），再到每一次的变更历史（history_record/），项目的一切都被显式地、结构化地记录下来。 - 可迭代与可追溯: 这种模式使得项目的任何状态都变得可追溯。我们可以清晰地看到一个功能是如何从一个用户故事，演变为架构设计，再到API和代码，最后被测试用例覆盖，并记录在历史中的。当AI或人类对项目有疑问时，答案就在这些文档里。
工作流程示例：一次功能的完整生命周期
让我们看看当操作员下达“开发用户登录功能”指令后，系统是如何运作的：
- 指令下达: 操作员向TOA agent发出指令。
- 计划与审批:
- TOA解析意图，选择
DEVELOP_FEATURE_WORKFLOW模板。 - 它生成一个多步骤计划，并向操作员汇报：“我将指挥架构师设计API和数据库，然后指挥工程师编码，再由测试人员验证，最后由管理员归档。我对架构师的第一步指令是‘...’。请批准。”
- 执行: 操作员批准后，TOA开始按顺序和依赖关系，依次向
架构师Agent、工程专家Agent、测试人员Agent和项目管理员Agent分发具体的任务指令。 - 状态变更: 每个Agent完成任务后，都会去维护其负责的文档。
service.md被更新了，backend/目录下出现了新代码，Test_instances/下增加了新的测试用例文件，history_record/中也多了一份本次任务的记录。 - 完成: 当
项目管理员Agent完成最后的归档工作并向TOA汇报后，TOA向操作员报告：“用户登录功能已完整上线，所有相关文档均已同步。”
至此，一次高质量、全流程可追溯的功能交付便完成了。
这是一些运营实例：
所有文档架构及Prompt都上传到了Github：https://github.com/weilaidewakaka/vibecoding-operating-system
整个项目迭代历程可以查看：https://www.nonconsensus.me/category/ai-technology/
对这个项目有兴趣的朋友可以去下载看一看，我自己的体验是，在当前的技术条件下，太重的智能路由并不可行，远不如手动执行工作流。主要原因还是subagent无法与主agent共享memory，这导致他们相对于主agent缺失了太多信息，并不“智能”。
强行给subagent注入memory也是可以的，但是又会继续降低运行性能。
但这套架构并不是一无是处，反而有很好的项目管理能力，只是还是要由人来作为智能路由（相当于本架构中的TOA agent）。在执行任务的时候，可以直接将某个agent的prompt拖到对话框，然后让AI以其为执行流程进行任务作业。这样AI既有流程约束又有全局记忆，还会自动管理文档，已经非常高效。
还有一种折中的方式，不要创建TOA这个agent，只把这份prompt当作任务引擎，随时把整个文档丢给AI让它执行，这样AI就是TOA本身了————这样TOA就具有了全局记忆，执行效率能高出很多。所以如果觉得subagent效率太低，不如把所有的agent prompt当作流程控制规则使用，这样每次执行者都是拥有全局记忆的AI本体。
另外，流程规范文档到底是按照元流程来写呢还是按照agent角色来写呢（比如一个架构师的角色会负责数据库更新流程、版本计划制定流程等等）？我觉得按照agent角色比较好，只要文档格式规范，其实浪费不了多少token，反而会让你这套体系拥有更好的扩展性，更“native”，因为最终你还是要指挥一个角色干活，而不是去亲手执行流程。
如你所见，这次智能路由系统的构建并不成功，但也许未来不久，智能路由就能完全实现。
但我还是会把它看成一个性价比的问题，而不是一个技术问题。