背景
标准 Agent Skill 现在不只含 prompt,还普遍带 scripts/ / references/ / assets/(如 Anthropic 官方 skill-creator、pdf、docx、xlsx、pptx)。
产物目前的 SKILL 支持:
- L1 发现注入 + L2
read_skill 读正文:内置、自包含。
- L1/L2 已带技能目录绝对路径(commit 57c7ed9),相对引用
scripts/x 可解析。
- L3 跑脚本 / 读资源:完全依赖产物装有文件/shell 工具,而唯一来源是 MCP(Desktop Commander)。
实测结论(mimo-v2.5-pro + 真实 skill-creator):skills.enabled 但 mcp 关闭时,read_skill 只能给"正文+目录",技能脚本/资源够不着,L3 形同虚设。也就是说"完全支持 Skill"目前隐含一个硬前提:必须开 MCP + 装 Desktop Commander(Node 系、需联网首装)。
提议
在 harness/skills.py(仅 skills.enabled 时生成)加一个极薄、默认关、走 allowlist + HITL 的内置工具 run_skill_script,让产物不依赖 MCP 也能跑技能自带脚本——补齐 L3 的"脚本"半边。资源读取(references/assets)L2 的 read_skill 思路可另配一个 read_skill_file(只读、低风险),本 issue 先聚焦脚本执行。
设计草图(待评审)
@registry.tool(name="run_skill_script", risk=HIGH, ...)
def run_skill_script(skill: str, script: str, args: list[str] | None = None) -> str:
# 1) 经 discover_skills 解析 skill -> 限定在已配置 skills.dirs 内(skill 不存在则拒)
# 2) script 相对技能目录解析后 .resolve(),断言仍在技能目录内(挡 ../ 逃逸)
# 3) subprocess 跑,cwd=技能目录,带 timeout,stdout/stderr 截断(复用工具结果截断口径)
# 4) 返回退出码 + 截断后的输出
- 风险姿态:
risk=HIGH → 默认不在 allowlist、confirm: high 下逐次 HITL、非交互 fail-closed——与 DC shell 同级。
- 薄:只用 stdlib
subprocess;skills.enabled=false 时零痕迹;不进默认核心依赖。
- 路径围栏:只能跑"已发现技能目录"内的脚本,
../ 逃逸拒绝(这是工具自身的输入校验,非安全边界——真隔离仍靠 Docker)。
需要人拍板的点(命中 CLAUDE.md §6)
- 定位红线软化:slice-6 §0 明确"基线能力全来自 MCP、产物不自写实用 built-in"。本工具是产物自写的脚本执行 built-in,虽默认关 + 仅 skills 下生成,仍是对该定位的有意松动 —— 要不要做、是否只在 skills.enabled 下、是否标注为 skills 专属(只跑技能目录内脚本、不做通用 shell),需签字。
- 解释器范围:只支持
.py(走当前 sys.executable,覆盖 Anthropic 文档系技能的绝大多数),还是也支持 .sh/任意可执行?倾向先只 .py,shell 仍交给 MCP,保持薄。
- 与"安全面":新增本机任意(技能目录内)脚本执行面,文档需同步"勿对公网暴露 / 本地可信"口径(同 DC/MCP 管理面)。
退出门禁(验收)
skills.enabled 才生成;默认不在 allowlist、risk=HIGH;skills.enabled=false 零痕迹。- 单测:路径围栏(
../ 逃逸 / 未知 skill 拒绝)、超时、输出截断。
- golden/mock:把它 allowlist 后,MCP 全关的产物仍能用
run_skill_script 跑通一个技能自带的 trivial 脚本并拿到输出。
skills.py 仍守 ~60–130 行薄预算(本工具约 +40 行,可能逼近上限,超则停问人,见 CLAUDE.md §6.8)。ReadLints clean;文档同步(slice-6 + overview §6 技能行 + 产物 README/AGENTS 安全面口径)。
参考
背景
标准 Agent Skill 现在不只含 prompt,还普遍带
scripts//references//assets/(如 Anthropic 官方skill-creator、pdf、docx、xlsx、pptx)。产物目前的 SKILL 支持:
read_skill读正文:内置、自包含。scripts/x可解析。实测结论(mimo-v2.5-pro + 真实
skill-creator):skills.enabled但mcp关闭时,read_skill只能给"正文+目录",技能脚本/资源够不着,L3 形同虚设。也就是说"完全支持 Skill"目前隐含一个硬前提:必须开 MCP + 装 Desktop Commander(Node 系、需联网首装)。提议
在
harness/skills.py(仅skills.enabled时生成)加一个极薄、默认关、走 allowlist + HITL 的内置工具run_skill_script,让产物不依赖 MCP 也能跑技能自带脚本——补齐 L3 的"脚本"半边。资源读取(references/assets)L2 的read_skill思路可另配一个read_skill_file(只读、低风险),本 issue 先聚焦脚本执行。设计草图(待评审)
risk=HIGH→ 默认不在 allowlist、confirm: high下逐次 HITL、非交互 fail-closed——与 DC shell 同级。subprocess;skills.enabled=false时零痕迹;不进默认核心依赖。../逃逸拒绝(这是工具自身的输入校验,非安全边界——真隔离仍靠 Docker)。需要人拍板的点(命中 CLAUDE.md §6)
.py(走当前sys.executable,覆盖 Anthropic 文档系技能的绝大多数),还是也支持.sh/任意可执行?倾向先只.py,shell 仍交给 MCP,保持薄。退出门禁(验收)
skills.enabled才生成;默认不在 allowlist、risk=HIGH;skills.enabled=false零痕迹。../逃逸 / 未知 skill 拒绝)、超时、输出截断。run_skill_script跑通一个技能自带的 trivial 脚本并拿到输出。skills.py仍守 ~60–130 行薄预算(本工具约 +40 行,可能逼近上限,超则停问人,见 CLAUDE.md §6.8)。ReadLintsclean;文档同步(slice-6 + overview §6 技能行 + 产物 README/AGENTS 安全面口径)。参考
feat(skills): surface each skill's directory ...)。docs/02-development/07-slice-6-tools-and-skills.md;多模态/文件处理调查 调查: 产物对 xls/doc/ppt/pdf/图片的处理能力(无上传/无多模态)与改进方案 #4(同属"产物实际干活能力")。