感知工具的主要挑战是什么？
- 挑战: 返回信息量常远超 Agent 的处理能力——一次搜索可能返回数万个字符，一份 PDF 可能多达上百页，直接塞入上下文既耗尽窗口空间，又让关键内容淹没在噪声中;
- 通用做法: 在工具层面集成上下文感知压缩——当输出超过阈值（如 10000 个字符）时，基于 Agent 当前的查询意图自动压缩;
- 展开位置: 压缩原理见第二章，此处不展开;
搜索类工具应返回什么？
- 格式: 结构化的候选列表（标题、位置、摘要片段），而不是拼接后的全文——让 Agent 先浏览候选，再决定深入读取哪一条;
- 分页: 结果数量较多时提供分页或游标（cursor）参数，默认只返回前若干条，并在返回值中注明结果总数和获取下一页的方式;
- 决策权: 由 Agent 自主决定是否继续翻页，而不是一次性倾倒全部结果;
读取类工具如何处理截断？
- 参数: read 类工具应支持 offset/limit，按需读取大文件的指定片段;
- 显式截断: 内容超过阈值必须截断时，应明确标示省略了多少内容、如何读取剩余部分，例如“已显示第 1-200 行，共 5000 行，可用 offset 参数继续读取”;
- 风险: 静默截断是危险的——Agent 会误以为自己看到了全部内容，基于不完整的信息做出错误判断;
只读性带来哪些工程红利？
- 缓存: 相同查询在数据未过期时直接复用，节省时间与费用；但缓存键仍需包含用户身份与授权范围，并为天气、股价、搜索结果这类会变化的数据设置 TTL;
- 并行: 多个感知工具调用适合并行执行（如同时读取五个文件、并发发起三个搜索），不必担心相互改写状态;
- 注意: 需留意速率限制，以及多次读取之间外部数据发生变化导致的快照不一致;
- 对照: 执行工具没有这种自由——调用顺序和副作用都必须严格控制，见 执行工具的安全分层;
多模态内容应以什么形态返回？
- 图像路线: 直接返回图像交给具备视觉能力的模型，保留布局和视觉细节，但消耗更多 token;
- 文本路线: 先用 OCR、图表解析等手段转成文本，精简高效，但可能丢失关键的空间结构（如表格的行列对应关系）;
- 选择: 纯文字内容用文本提取，布局敏感的内容（UI 界面、复杂表格、设计稿）保留图像;
- 展开: 三条实现路径见 多模态感知的三条路线;