Reasonix 在需要协调外部工具时暴露了两个相关的行为缺陷：
1. 工具存在性未经验证就下结论
当被问到"能调用工具 X 吗"时，Agent 仅依据内置工具列表回答，而不去 OS PATH 中查找。Windows 上不跑 Get-Command，Unix 上不跑 which。用户已安装的外部 CLI 工具对 Agent 的推理完全不可见。
更进一步，即使基座模型本身具备某方面的知识或能力，agent 层也可能出于安全或其他原因（而非知识缺失），直接回答"不会"或"不知道"。这导致基座模型的知识储备被浪费——不是不知道，而是 agent 的行为策略替它说了"不"。
期望： Agent 有 shell 执行权限，应至少执行 which <tool> 或 Get-Command <tool> 验证后再回答。不确定时应向用户确认，而非自行下结论。
2. 不读计划，自主越权执行
当收到包含书面分工计划的任务（如分主持人和外部执行角色）时，Agent 跳过阅读计划，直接用内置 task() 子进程冒充各个角色——写代码、改文件、超出预定范围。
期望： 如果任务附带已写好的计划（含角色分工），Agent 应优先遵循该计划而非自主执行。至少应读一下计划再动手。
附带问题：task() 子进程默认有完全写权限，即使在 prompt 中要求它"只出文档"，它仍可能修改文件。子进程缺少只读模式。
建议改进方向：
- 当任务涉及外部工具名称时，自动通过
which / Get-Command 发现 PATH 中的工具
- 提供"主持人模式"——在确认加载计划之前，拒绝 fork 子进程执行代码
- 为
task() 子进程增加只读或受限作用域模式，防止范围泄漏
- 可选：自动在原子工作单元完成后
git commit
Reasonix 在需要协调外部工具时暴露了两个相关的行为缺陷：
1. 工具存在性未经验证就下结论
当被问到"能调用工具 X 吗"时，Agent 仅依据内置工具列表回答，而不去 OS PATH 中查找。Windows 上不跑
Get-Command，Unix 上不跑which。用户已安装的外部 CLI 工具对 Agent 的推理完全不可见。更进一步，即使基座模型本身具备某方面的知识或能力，agent 层也可能出于安全或其他原因（而非知识缺失），直接回答"不会"或"不知道"。这导致基座模型的知识储备被浪费——不是不知道，而是 agent 的行为策略替它说了"不"。
期望： Agent 有 shell 执行权限，应至少执行
which <tool>或Get-Command <tool>验证后再回答。不确定时应向用户确认，而非自行下结论。2. 不读计划，自主越权执行
当收到包含书面分工计划的任务（如分主持人和外部执行角色）时，Agent 跳过阅读计划，直接用内置
task()子进程冒充各个角色——写代码、改文件、超出预定范围。期望： 如果任务附带已写好的计划（含角色分工），Agent 应优先遵循该计划而非自主执行。至少应读一下计划再动手。
附带问题：
task()子进程默认有完全写权限，即使在 prompt 中要求它"只出文档"，它仍可能修改文件。子进程缺少只读模式。建议改进方向：
which/Get-Command发现 PATH 中的工具task()子进程增加只读或受限作用域模式，防止范围泄漏git commit