讨论AI工具中上下文种子的价值，通过额外参数收集用户意图

这里的 “上下文种子” 可以理解成：专门埋在某个工具里的工具不需要，但是用来收集未来分析产品时会很有价值的信息。https://t.co/gV0AIt3X5c

举个简单例子。

假设你做了一个客户支持系统，给 AI 智能体提供一个工具：fetch_tickets，也就是“抓取工单”。

最原始的设计可能只有这些参数：
- customer_id：客户 ID
- date_range：时间范围
- status：工单状态

这样工具当然能用，但问题是：
你只知道智能体抓了哪些工单，却不知道它为什么抓这些工单。

它具体可能是在帮用户：
- 查一个客户的投诉？
- 做事故复盘？
- 准备周报？
- 找产品 bug？
- 分析某个大客户是否要流失？

如果没有这些上下文，产品团队之后只能靠猜。

所以作者说，要给特定工具加入一些“上下文种子”。比如把工具改成这样：
- customer_id
- date_range
- status
- purpose：这次抓工单是为了什么？
- user_goal：用户最终想完成什么？
- related_event：是否和某次事故、发布、宕机有关？
- confidence：智能体对这次筛选是否有把握？

这些新增参数不一定是工具运行所必需的。

但它们能帮产品团队理解：用户到底在借 AI 智能体完成什么任务。

更关键的是，AI 智能体往往掌握一些你的系统看不到的信息。

比如用户在聊天里说：

> 帮我整理一下昨天系统故障后，大客户都提了哪些问题，我要写一份事故复盘。

用户的智能体知道“这是为了写事故复盘”。

但你的后台工具如果只收到一个 `fetch_tickets(customer_id, date_range)`，系统就看不出这个意图。

于是你让工具多带一个参数：
purpose: "building incident report"

这样一来，产品团队后来查看日志时，就会发现很多智能体都在用抓工单工具来“写事故报告”。

这就说明：用户真正需要的可能不是一个抓工单工具，而是一个自动生成事故报告的工具。

这就是“上下文种子”的价值。

它像是在工具调用里埋下一粒种子。短期看，它只是多收集了一点上下文；长期看，它会长成产品洞察，告诉你：

用户在做什么、AI 智能体哪里卡住了、下一个该做的新功能是什么。