同一个能力，做成功能和做成工具，长期价值差一个量级。
**功能只能被点击。**它长在某个页面的某个位置，有自己的按钮、表单和结果区。用户必须先知道它在哪，走到那里，然后用。
**工具能被调用。**它有名字、有参数、有明确的返回，谁都能调——你自己的 Agent、用户装的别的助手、合作方的系统。它不要求任何人先找到它。
在 Agent 时代，这个区别决定了你的能力能走多远。
一套定义，两个出口
做工具最容易犯的错，是内外两套实现。
内部 Agent 用一套，对外开放时另写一套接口，两边慢慢各说各话——参数含义漂了，边界条件不一致，改一边忘一边。半年后没人敢动其中任何一边。
正确的做法是同一套定义，两个出口。工具只定义一次：它做什么、要什么参数、返回什么结构、什么情况下报什么错。内部编排调它，对外协议也暴露它。
这件事的附带好处很实在：因为对外要面对陌生的调用方，你被迫把每个工具的语义写清楚。而这份清楚，反过来让你自己的 Agent 用得更准——含糊的工具描述是 Agent 调错工具的头号原因。
按读写分级，不按重要性分级
对外开放不等于全部放开。
我的分法很简单：**读类工具可以开放，写类工具留在自己的权限环里。**查询历史、搜索、估算、分析——这些开放出去，最坏情况是被人多查几次。创建订单、修改状态、发送消息——这些不开放，或者只在完整的授权链路里开放。
不要按「重要性」分级。重要的工具往往正是最该开放的那些，因为它们最能证明你的数据价值。真正的分界线是这次调用会不会改变世界。
不是所有问题都值得走深度链路
有了一堆工具之后，下一个问题是什么时候用它们。
全部问题都进多工具深度链路，成本和延迟会立刻失控；全部走轻量直答，复杂任务就废了。所以要做轻重路由：简单问题直接回答，复杂任务才展开规划、并行取数、整合交付。
路由本身是个产品决策，不只是技术优化。它决定了用户问一句话要等三秒还是三十秒，而这两种体验对应的是完全不同的使用场景——三秒的那种会被随手用，三十秒的那种必须值回票价。
记忆：跨会话，只增，按人隔离
工具让 Agent 能做事，记忆让它不必每次从零开始。
三条我认为没得商量的原则：
- **跨会话。**记忆的价值全在会话之间。同一个用户第二次来，系统该知道他上次关心什么、习惯什么格式、用哪种语言。
- **只增不改。**新的偏好覆盖旧的，但不要让系统去「修正」历史记录。改历史的系统没法解释自己。
- **按人隔离。**读写边界严格按用户身份划。这条在多租户场景下是红线，不是优化。
还有一条经验：记忆要有滚动窗口。无限累积的上下文不是更聪明，是更贵、更容易被无关信息带偏。
边界
**不是所有能力都该做成工具。**只被用过一次的、逻辑高度耦合在某个页面里的、语义说不清楚的——硬做成工具只会让工具列表变长。工具列表越长，Agent 选错的概率越高，这是实打实的成本。
**开放是要运营的。**放出去之后要有账号授权、订阅校验、额度管理和调用记录，否则你不知道谁在用、用得对不对、是不是该收费。把工具扔出去就不管，跟没做一样——只是多了一个你无法解释的流量来源。