我构建了一个智能体引擎，其编排逻辑存在于文本文件中而非代码中——这就是为什么这很重要

大多数智能体框架都存在同样的四个耦合问题：工具在代码中定义、每轮都发送完整工具目录、编排逻辑与框架绑定，以及需要重新部署才能更改的静态目录。我一直在构建 VITA，一个认知引擎，其编排层以纯文本（.md 文件）声明，并在请求时由通用引擎解释。与通常做法的一些具体区别：工具是 .md 文件中的一块文本，而不是带装饰器的 Python 函数。工具定义本身没有框架锁定。模型永远不会看到完整目录。每一步只获得与该步骤相关的工具——不是因为摘要，而是因为下一步在到达之前根本不会显示。每次请求都会从磁盘重新读取目录。添加或更改能力不需要重启进程。按构造即与提供商无关。相同的目录、相同的 .md 文件，适用于 Groq、Gemini、OpenRouter 等——切换提供商不会触及工具定义。一个通用分派点可以解析任何转换，而无需事先知道它在分派什么。明确一下范围：这并不是声称它胜过 LangChain、MCP 或由拥有多年生产环境打磨经验的团队构建的多智能体框架——它没有，而且这不是卖点。比较范围更窄：编排逻辑到底在哪里——在模型中、在代码中，还是在介于两者之间的声明层中。这一个设计决策，贯穿了三次完整的引擎重写，才是我认为这里真正站得住脚的地方。我很乐意深入讨论架构（有更完整的技术文档），如果有人想要具体细节——也愿意听取我尚未看到的失败之处。—— 来自阿根廷萨尔塔的独立开发者。