感谢评论，针对评论中提到的 AI 编程瓶颈，分享一下 AnyPal 架构上的工程解法：

上下文控制
AnyPal 引入敏捷开发（ Plan ）模式，通过工程级任务拆分与依赖关系分析，将复杂需求解构为若干个可在 256K 上下文内单次完整迭代的工单，工单下再细分多个子任务。由于单次迭代被严格控制在 256K 标称容量内，执行过程中几乎不需要进行 compact 上下文的操作，避免上下文压缩导致降智。

多维度的复合记忆系统
AnyPal 放弃了单一的长文本挂载，转而构建多层级的记忆矩阵来支撑 Agent 决策：

计划记忆：沉淀软件顶层设计、与当前工单强绑定的代码修改历史、以及工单内的讨论与评论内容。

经验记忆：自动记录并结构化每次修复 BUG 的根因与应对措施，形成随项目进化的本地经验本。

全局理解：在本地基于 Tree-sitter 对项目进行 AST 语法树解析和依赖拓扑建模，将代码关系向量化。AI 拆解工单时直接检索该图谱以精准定位局部关联文件，避免盲目全盘扫描造成上下文灾难。

多 Agent 对抗约束
AnyPal 内置了 6 个反方角色（测试驱动开发、威胁建模、本地化等），在底层抽象层引入强工程约束与权限隔离，避免大模型在 Chat 框内相互敷衍。以测试驱动开发模式为例：

权限隔离：反方（ Critic ）是测试文件的唯一合法编写者。若正方（ Coder ）试图修改测试路径文件以迎合其 Bug 代码，CoderTestGuard 会强行拦截。

沙箱运行：反方在安全沙箱中动态编写并运行真实测试（如 Vitest / Pytest 等），将测试结果作为 Evidence 注入结构化 Check-list 倒逼 Coder 改错。只有 Check-list 验收通过且完成验证调用，AI 会话才能 Finalize 结账。

关于 IDE
AnyPal 支持 VSCode 插件形态，但受限于环境，功能仅支持对抗式编程。

关于对比测试确实有些脱离实际且存在操作失误，我们后续会采用真实业务场景和标准产品 PRD 对比测试，感谢您的建议。

@azadmin 欢迎进群反馈，开发会直接跟您沟通

@Orchestraa 明白了 下次发推广

@dayuzhu Mac 端还在走流程，预计 3 天后上线

@Varvel 抱歉了，开了搜索也搜不到，不知道什么原因，http://anypal.net/网页底部有二维码