1. AI agent tool design: build tools a model can actually use

推荐理由： 这篇不是抽象的 tool-calling 最佳实践，而是把同一个 debugging task 放进冻结的 Agent harness，只替换 tool layer，做了 54 次运行。所有运行最终都完成任务，但不同 tool 设计让输入 token 和成本差出一个数量级以上。它很好地说明：tool interface 本身就是 context engineering，Agent 做出昂贵或错误决策，往往不是模型不会推理，而是前一个 tool result 没给它足够的决策信息。

核心要点：

  • Tool 的真正接口是模型能看到的四样东西：name、description、input schema 和 result。 模型看不到函数实现，只会根据这些文本选择工具、填参数并理解执行结果；因此 tool design 本质上同时是 API design 和 prompt/context design。这个接口模式在 Anthropic、OpenAI、Gemini 之间基本可迁移，MCP 主要改变发现与传输方式，并不会替你把工具接口设计好。
  • 把“调用成本”放到 Agent 已经会看的廉价结果里，比事后限制更有效。 实验中，只是在 list_dir 返回里加入文件 byte size，就让 Haiku 4.5 对一个 238 KB CSV 的整文件读取从 9/9 次降到 1/9 次；中位输入 token 从约 1,004,922 降到 21,627，按未缓存列表价计算约从 1.01 美元降到 0.03 美元。作者也明确提醒，这个绝对成本差会被 prompt caching 缩小，但行为差异仍然成立。
  • 语义歧义比 schema 不严格更危险。 run_node(script) 被模型理解成“传入源码”，而实现实际期待文件路径，导致连续无效调用；改成 run_node_file(path) 并明确说明后，错误显著减少。strict: true 只能约束参数形状，不能保证语义正确，所以命名、返回值和 actionable error 才是 Agent 修正错误信念的关键。

核心启示：Agent tool 不应只追求“功能可调用”，还要把下一步决策需要的成本、规模、风险和恢复信息放在模型最早能看到的位置。一个好的 tool layer 应让模型在昂贵调用发生之前就能判断“值不值得做”。

2. AI Security Is an Engineering Problem — How to Solve It at Every Layer of the Agent Stack

推荐理由： 这篇把 Agent 安全从“写更好的 system prompt”拉回到传统工程控制：身份、权限、网络边界、执行环境、工具供应链、日志和验证证据。它尤其适合 AI-native software factory，因为当 coding agent 能操作仓库、CI、云资源和内部系统时，真正的安全边界必须位于 Agent reasoning 之外。

核心要点：

  • 安全责任分布在完整 Agent stack，而不是模型单点。 Model 负责能力，harness 组织 context / tools / workflow，runtime environment 决定文件、网络和进程真正能做什么。即使 Agent 被 prompt injection 误导，外部 network policy、filesystem policy 和 permission boundary 仍应阻止越权动作。
  • 每个 Agent 都需要可追踪身份和最小权限。 凭据应该限定到具体任务，更新客户数据的权限不应自动意味着可以导出数据；权限升级、敏感动作和高后果操作仍需要独立审批。与此同时，skills、tools 和 dependencies 的来源与完整性也必须可验证，避免把供应链风险直接带入执行环境。
  • 安全必须产生可重复的证据。 部署前应测试越权取凭据、外传敏感数据、修改权限、干扰监控等行为；模型、工具或 workflow 有重大变化后需要重新测试。运行时保留受保护的 tool-call、授权决策和结果日志，并把真实事故转化为 regression tests，才能形成持续改进闭环。

核心启示：生产 Agent 的安全模型应是 traceable identity → least privilege → sandbox/network enforcement → tool provenance → protected audit logs → repeatable security evals。Prompt guardrail 可以降低风险，但不能承担最终授权与隔离责任。