🏠 home › concepts › agent-tool-design
tags
[AI, Agent, 工具, 设计, Claude Code]
created
2026-04-12
updated
2026-04-28
sources
[raw/notes/anthropic-seeing-like-an-agent.md, raw/notes/hotmind-family-agent-spec-2026-04-17.md, raw/notes/huxuan-vibe-coding-games-2026.md, raw/notes/founder-park-creao-organizational-pivot-2026.md, raw/notes/zhao-saipo-work-experience-ai-skill-2026-04-27.md, raw/notes/karri-saarinen-some-notes-on-ai-2026-04-26.md]

定义

从 Agent 视角设计工具的方法论——理解模型需要什么能力和接口来做决策，而非基于开发者的便利。Anthropic 在 Claude Code 中总结的工具设计哲学。

关键要点

反向链路：工具不是 Agent → 环境单向

通常讨论的工具设计假设"Agent 调用工具影响环境"是单向。Hotmind 客户（hotmind-client）发给承包方的接口规范引入了第三段——环境 → 用户（通知 UI 刷新）+ 用户 → Agent（撤销）：

{
  "agent_name": "alarm_clock",
  "action": "created",
  "summary": "已创建明天7:30的闹钟",
  "resource_id": "...",
  "cancel_action": "alarm_clock_delete"   // ← 设备渲染"撤销"按钮
}

cancel_action 字段本质是Agent 把"撤销操作"的工具名也告诉了设备——设备 UI 不需要理解业务语义就能渲染撤销按钮。这要求工具集设计时显式标注每个"创建型"工具对应的"删除型"工具，构成可逆性配对。

含义：工具设计要考虑"操作可不可被用户撤销"这个维度，不只是"Agent 能不能正确调用"。这是 Sentino 自家 Standalone Agent 工具协议没有的能力——值得反向学习进 sentino-agent。

工具复用 vs 业务概念独立的取舍

Hotmind 客户接口规范的"用药提醒底层用闹钟实现"是工具复用的样本——业务有 6 个模块（闹钟/日历/待办/用药/积分/习惯），底层工具只有 4 套，剩下靠 Agent 的 prompt 选择语义区分。

代价：Agent 必须正确选择"这是用药场景所以推荐每天重复 + 删除时确认"的语义，工具本身不强制——这把可靠性责任从工具层挪到 prompt 层。详见 hotmind-client。

反向：Coding Agent 是 connector 的元工具

CREAO 在 2026-04 Founder Park 访谈中给传统"工具集设计"加了一个反向论点：Coding Agent 是工具集设计的元工具——不需要平台预备所有 connector，agent 可以现写代码现编译现运行解决长尾边界问题。

Amplitude 案例

用户拿最新 10 封邮件可以调 connector，但拿到后定制化处理就是边界情况——以前需要平台方提前做好 connector，Coding Agent 现写代码现编译现运行直接交付。

CREAO 内部具体执行： - 原本需要自己开发 Amplitude connector 提供授权接口 - 现在用户跟 agent 描述需求 → agent 一步步写出连接代码 → 告诉用户登录 Amplitude 给 TOKEN → 直接 access 所有数据

"用户所有基础工具的连接现在都可以实时完成，不再依赖平台方提前把所有 connector 做好。"

Marketing 抓取案例

CREAO marketing 同事每天生成竞品分析报告 → 每个网站结构不一样不可能预备 parser → Coding Agent 现场写抓取代码 + 遇阻自调整 → 跑通后变成 rerun agent 每天自动跑。

对工具集设计原则的颠覆

传统工具集设计：平台预备 connector 集合，工具粒度由平台定义。

Coding Agent 视角：Coding Agent 是 connector 的元工具——平台预定义工具集是为常用路径优化，长尾通过 agent 现写代码兜底： - 这是 mcp-protocol 的反向：MCP 是"先定协议"，Coding Agent 是"现场写" - 这与本页"反例：vibe coding 平台不支持外部资产导入"互补——vibe coding 主张是"什么都不让 agent 做"，CREAO 主张是"让 agent 写代码做任何事" - "Coding Agent 覆盖长尾 general 问题的范围比'调接口'要宽得多"

对 sentino-agent Standalone Agent 工具集设计的启示：当前 Sentino Standalone Agent 工具集是平台预定义（read_xx / 调 API）。如果引入 Coding Agent 能力（让 agent 自己写抓取/解析代码），可以大幅扩展长尾覆盖——但需要 sandbox 隔离 + 安全审计配套（agent-runtime-architecture Layer 5）。这与本页 "逃生工具" 设计哲学是同源升级——"逃生工具"是让用户自己带工具，"Coding Agent 元工具"是让 agent 自己造工具。

Skill 在企业落地的所有权问题（2026-04 现实约束）

CREAO 给的 Skill 定义（"Agent 的 Runbook"）是技术视角。2026-04 同事.skill 事件 + 中国公司"写 skill 进考核"现象（详见 work-experience-ownership）显示了 Skill 在企业现实落地的另一层约束：

对 Sentino sentino-agent Standalone Agent 设计的具体含义：当 Sentino 给企业客户卖"创建你自己的 standalone agent"时，需要前置回答客户的员工写出来的 agent prompt + 工具配置归谁——是雇员个人？业务部门？整个公司？这条不在产品技术层，在合同条款层，但客户实际购买决策时会问。

Skill vs Agent 的层次区分

CREAO Peter 在同一访谈中给 Anthropic Skill 系统和"完整 Agent"一个清晰的区分：

Skill = Agent 的 Runbook
    └── 一个文档文件让 Agent 从基础设施层面正常运行
    └── 是更底层一层设计

Agent = Skill + Memory + Widget + Schedule
    └── Skill 之上还有 Memory（跨会话）
    └── Widget（展示层）
    └── Schedule（调度机制：怎么触发、怎么定期运行）

含义：Skill 不是终极抽象，Agent 比 Skill 多三层。在 agent-runtime-architecture 七层模型中，Skill 在 Layer 7（扩展层），但完整 Agent 还需要 Layer 3（Memory 预取）+ Layer 6（Task 调度）+ UI 层。

对 Sentino Standalone Agent 设计的启示：当前 Standalone Agent = "指令（prompt）+ 工具选择 + 触发条件" — 这覆盖了 Skill（Runbook） + Schedule（触发条件），但 Memory 和 Widget 是隐性的： - Memory 由主 Agent 通过 read_xx 工具被动查 latest——而非 Standalone Agent 自己有 Memory（这是设计选择） - Widget 在 Sentino 当前是"语音输出"——主 Agent 通过统一人格读出来，没有图形展示层

如果未来要扩展 Standalone Agent 形态（如纯 App 内查询、Web Dashboard、Webhook 推送），Widget 层会变得关键——这是 Skill→Agent 升级路径上的下一个工程点。

"用户能并行运行多少 agent" 是工具设计的隐藏约束

Linear CEO Karri Saarinen 在 2026-04-26 X 长文给"agent 并行数"提供了一个工具设计层常被忽略的人因约束：

"Engineers are still very much involved in the steering the agent, and often can maybe can only run couple of agents at once, and few cloud agents in the background to do more menial fixes. Any more than that you're living in the world of Harrison Bergeron where something constantly pings you and disrupts your thinking process."

Vonnegut《Harrison Bergeron》里的反乌托邦设定：智者每 20 秒戴耳机被噪音打断思考，无法连续推理。Saarinen 把"工程师并行运行过多 agent" 类比为 Harrison Bergeron——每个 agent 的中断请求 / 状态更新 / 选择确认会切碎人的注意力，到一定数量后人类不再能做有效 steering。

对工具设计的具体含义：

设计选择 影响
Agent 主动推送式（每完成一步要确认） 并行天花板低（2-3 个 agent 就饱和）
Agent 异步批处理式（攒到一定阶段才汇报） 并行天花板高（数十个 cloud agent 后台跑）
Agent 静默兜底式（完成后才知道、有问题才打扰） 并行天花板最高

Linear 自家实践："own cloud coding agent" 走的是"静默 + 完成提交 PR" 路径，所以可以做到每月修 1000+ issues 且不让工程师全员被干扰。

对 sentino-agent Standalone Agent 的具体启示：

与本页"渐进式披露"原则的关系：渐进式披露处理的是单 agent 内部信息层级（主 agent 不被子 agent 上下文污染），Saarinen 视角处理的是多 agent 对单人类的注意力总和——两者方向一致：减少非必要信息向上层传递。

反例：vibe coding 平台的工具集设计缺陷

腾讯研究院 2026-04 vibe coding 长文（→ vibe-coding-creator-motives）观察到 vibe coding 游戏开发平台普遍存在一个根本性工具设计问题——美术资产生成工具能力薄弱 + 不支持外部资产导入：

平台自己生成资产能力很弱（基本是色块组合，低多边形模型有限），不支持外部导入用户已有美术资产，不支持图片视频参考生成 UI 界面和场景元素。结果是大部分 AI 创作的游戏呈现"毛坯房粗粝感"。

这是工具设计原则的反例——当工具能力跟不上用户实际需求时，不应封死外部资产入口。Anthropic Claude Code 的工具设计始终保留 Read/Write 让用户带入任意文件，这是把"工具能力不足"的退路留给了用户而不是封死。

对 sentino-agent 的启示：Standalone Agent 的工具集设计要分两类—— - 核心工具（平台精心设计、保证质量） - 逃生工具（让用户/客户带入任意外部资源 / 自定义工具）

把所有能力都收在自家工具集里，既增加平台维护成本，又锁死用户在能力不足时的求生路径。

相关概念