Agent 不该聪明，应该可控

——一个 command-first 的 agent skills 架构

最近在做 agent 相关系统时，有一个问题反复出现：

agent 太“自由”了。

• 会 guessing
• 会 fallback
• 会在你没明确授权的情况下用工具
• 不同环境下行为不一致
• 出问题了也很难说清「它到底干了什么」

这在 demo 里也许还能接受，
但在真实系统里，这是灾难。

一个很简单的问题

如果一个行为没有被明确写成 command，
那 agent 凭什么可以执行？

如果一个能力：

• 没有被明确列出
• 没有清晰的输入输出
• 没有声明可用工具
• 没有失败或中止条件

那它本质上就是一种 不可控的隐式行为。

---

一个反主流的选择

所以我做了一个非常“反 agent 潮流”的框架。

我没有试图让 agent 更聪明，
而是把它当成：

一个受限的指令执行引擎，而不是智能体。

核心原则

这个框架只有几条非常硬的规则：

1. Command-first

• 所有能力必须显式定义为 command
• 自然语言不是接口

---

2. List is the law

• 每个 skill 都必须提供 list
• list 定义了 完整且唯一 的可执行空间

不在 list 里的行为 = 不存在

---

3. Abort over guess

• 有歧义 → abort
• 工具不可用 → abort
• 环境不支持 → abort

不允许 guessing，不允许 fallback。

---

4. No hidden power

• 不允许隐式工具
• 不允许未声明能力
• 不允许“顺便做点别的事”

---

一个最简单的例子

READ
  read <file_path>

HELP
  list

• 就这些。
• agent 只能执行这些 command
• 不能推断「你可能想要」
• 不能自行组合 workflow
• 不能“试试看”

这不是能力不足，而是刻意的设计选择

---

为什么要这么严苛？

因为我关心的不是：

• agent 能不能多做点事

而是：

• 它会不会做错事
• 行为能不能被审计
• 失败能不能被复现
• 不同环境下是否一致

这个框架适合：

• 生产环境 agent
• tool-heavy / infra 场景
• 对可预测性要求极高的系统

它不适合：

• 创意型 agent
• 探索式任务
• “让 agent 多试几次”的场景

---

技术本质

从结构上看，这是一个：

Agent 的 Instruction Set Architecture（ISA）

• skill = 指令集
• command = syscall
• tool = 受限绑定资源
• agent = 执行引擎

不是 prompt 魔法，
而是 通过结构约束来获得稳定性。

---

项目状态

• spec-first（规范优先）
• 没有 demo，没有 UI
• 重点不在“好不好用”，而在“会不会失控”

唯一目标只有一个：

把 agent 的行为空间钉死。

GitHub：
👉 https://github.com/qiuy-collab/PCAF-Personal-Command-Based-Agent-Framework

---

最后一句话

智能不是问题，失控才是。