很多内置工具是否能用bash代替？

[victorygod]

请问下Author大佬，我看到内置工具有很多：像move_file、copy_file、delete_file、create_directory、delete_directory等等，这些可以简单被规则做前置拦截的tool为何不能都是用bash来执行呢？放在工具列表感觉会加重上下文负担，这个负担感觉应该由harness来承担而不是模型吧？deepseek我记得R3之前就对bash（windows/linux/macOS）支持良好，做前置安全规则判断和后置备份拦截应该更加安全和省上下文吧？

[esengine]

@victorygod Two layers — token cost and correctness.

Token cost — tool specs do take prompt space, but they're encoded once in the ImmutablePrefix and hit the DeepSeek prefix cache on every subsequent turn ($0.028/M input-cache-hit). In a real session that's sub-cent fixed overhead, not a per-turn recomputation. This is the exact shape Reasonix is built around — cache-first means the spec table is essentially free after turn 1.

Why not just bash —

• Cross-platform: mv / cp / rm semantics differ on bash vs cmd.exe; the native tools call Node's fs and bypass the shell-quoting fork (which is already a chunky branch in tools/shell.ts).
• Path-scope safety: move_file({ src, dst }) is a struct, so the harness can decide before dispatch whether either path escapes rootDir. Doing the same against an arbitrary bash string means parsing shell — fragile.
• Structured output: tools return JSON the loop can consume; bash returns stdout/stderr the model has to re-parse.
• Reversibility: the planned auto-commit / per-edit checkpoint chain needs structured tool calls. A bash rm is opaque to the harness — no clean undo entry.

Bash is still there — run_command covers the cases that genuinely want shell pipelines. Both surfaces coexist on purpose; the model picks structured for primitives, shell for orchestration.

If the underlying ask is that the fs tool list is too long, that's a separate cut — whether directory_tree and list_directory should merge, whether get_file_info earns its slot, etc. Open an issue with a specific consolidation and I'll look.