设计讨论：用户自定义工具的引入机制

[JiGuangWorker]

背景

当前 code-bee 智能体的"工具"能力完全硬编码在平台适配层（internal/platform/）的 BuildSkillInstruction 中，没有独立的工具抽象层。这意味着：

1. 用户无法自定义工具来扩展智能体的能力边界
2. 不同项目/团队无法引入自己特有的工具集
3. 工具能力随平台适配器耦合，难以独立演进

需要讨论的问题

1. 工具的定义形式

工具本质上是一段结构化描述（名称 + 用途说明 + 使用约束），最终注入到 prompt 中供智能体使用。目前考虑两种定义方式：

• 配置文件声明：用户在项目根目录放置 .code-bee/tools.yaml，声明自定义工具
• 代码注册：通过 Go 接口注册工具，编译时确定

2. 工具的来源

• 内置工具：项目预定义的常用工具（如代码搜索、文件操作、测试执行等），所有用户默认可用
• 用户自定义工具：用户通过配置文件声明的工具，运行时加载
• 第三方工具引入：是否支持从外部仓库/URL 引入工具定义？

3. 工具的加载与合并

• 内置工具和自定义工具如何合并注入到 prompt？
• 当自定义工具与内置工具冲突时，优先级如何处理？
• 工具描述的长度/token 预算如何控制？

4. 安全边界

• 自定义工具是否需要有沙箱/权限控制？
• 如何防止恶意工具描述误导智能体行为？

建议的讨论方向

1. 先确定最小可用方案（MVP）：配置文件声明 + 运行时加载
2. 再讨论扩展能力：第三方引入、权限控制等
3. 工具定义格式需要兼顾简洁性和表达力