自动关联目录：能力边界：模型负责提出变更，不负责证明变更正确

核心判断：AI 可以扩展“提出候选方案”的带宽，但编译器、验证器、Client/DS 运行证据和责任人共同决定方案能否接受；把模型接上工具，不等于把工程权威交给模型。

一、业务冲突

客户端需求横跨代码、脚本、场景、资产、UI、动画、物理、网络和构建。AI 最有价值的地方是理解意图、跨文件查证、生成候选变更并驱动验证；最危险的地方也相同：一次看似合理的修改可能同时改变 Client、DS、编辑器和多个平台，而模型的解释力很容易被误当成正确性证明。

二、实际实现

实际工具链已经支持多种 Agent 执行后端、文件与 Shell 工具、编辑器桥接、生成资产、预览和视觉检查。可用 Agent 受用户角色与宿主能力约束；Plan 模式只暴露读取、搜索、计划和询问工具，并在 Schema 过滤之后再做一次执行期硬拦截，防止模型从旧上下文中“记起”写工具。

运行模式还能限制轮数、Token、费用和输入上下文；视觉验证返回结构化判定，并对“运动是否正确”这类单张截图无法证明的命题主动降级。说明工程已经认识到：模型输出是观察或建议，不是验收事实。

三、值得保留

角色门禁、Plan 模式双重拦截、预算限制和独立验证工具都应保留。它们把“模型能想到什么”和“系统允许它做什么”分开，也为代码、内容、Client 与 DS 使用同一 Agent 框架提供了最低安全边界。

四、结构性缺陷

现有能力仍主要按 Agent 模式和工具名组织，缺少“这项任务影响哪些可执行角色、是否可逆、由什么证据验收”的任务风险分类。能够调用预览或构建工具，不代表可以批准网络正确性、性能预算、安全边界或发布；视觉模型对自己生成的结果打分，也不能替代物理、复制和帧预算的确定性检查。

五、目标设计

先给任务分级，再选择模型和工具：

TaskPolicy Classify(TaskIntent intent) {
    return {
        affectedRoles: {Editor, Client, DedicatedServer},
        reversibility: ReversibleWithChangeSet,
        requiredEvidence: {Schema, Compile, Unit, ClientRun, ServerRun},
        authority: HumanOwner,
        maxToolScope: ScopedWorkspace
    };
}

Acceptance = DeterministicGates(change) && HumanApproval(change, evidence);

AI 适合检索、归纳、计划、生成候选 ChangeSet、补测试和分析失败；Schema、编译、协议重放、性能门禁、安全检查与不可逆提交必须由确定性工具产生证据，责任人作最终裁决。

六、取舍与验证

截至 2026-10-14，官方接口已经支持结构化输出、工具调用和 Agent 工作流评测，但官方文档同时明确：结构化输出仍可能在语义上犯错，高风险工具需要审批，隔离与结构化数据流只能降低而不能消除风险。Structured Outputs、Safety in building agents

验收能力边界时，要故意投放“能生成、但无法证明”的任务：网络协议改动、物理参数调优、跨平台资产替换和发布动作。系统必须要求对应的确定性证据，缺任一证据就失败关闭，不能因为模型自信或画面看起来正确而放行。