构建了一个代理工作站，让环境进行结构推理，从而减轻LLM的负担

我一直在构建Atlarix——一个专为编码代理设计的桌面环境——并且想与这个社区分享其核心架构洞见，因为它与代理设计直接相关。 我们不断遇到的问题：代理在大型代码库上失去连贯性，因为它们从原始文本中进行了过多的结构推理。 “在哪里进行身份验证？”不应该需要阅读50个文件——它应该是一个图查询。 因此，Atlarix没有注入原始代码，而是将仓库解析为节点/边图（房间=文件，信标=符号，边=导入/调用），通过oxc-parser处理TS/JS，通过WASM tree-sitter处理Python/Go/Rust。 代理调用get\_blueprint来导航架构，然后仅在需要时读取特定文件。 实际结果：较小的模型（7B本地）在架构感知任务上表现显著更好，因为环境承担了结构负载。模型只需推理和导航——它不需要在每一步都从头重建架构。 我们最终确定的其他设计决策： \- 模式感知工具白名单（探索模式实际上不能写入文件——不在注册表中） \- 每个破坏性操作的批准队列（文件写入、终端命令） \- 逐步上下文压缩，使长时间的代理会话不会失去线索 \- 按需MCP，而不是预先加载所有集成 免费层级支持本地模型（Ollama、LM Studio）。好奇这个社区中的其他人是如何处理结构化上下文问题的——你们是在构建环境层，还是依赖模型从原始文本中推理？