接口没报错，任务却被无关信息淹没
假设一个售后助手需要查明某张工单是否已处理。工具返回整位客户的历史记录、全部沟通文本和系统日志，真正需要的处理状态夹在中间。助手读了很多材料，却仍然回答含糊，甚至把另一张工单的结论带进来。这里的问题未必需要更换模型。
Anthropic 在 2025 年发布的上下文工程文章中强调，工具应提供信息密度合适的结果，并支持按需获取上下文。本文把这一思路用于企业接口设计讨论，属于技术解读。它不是某项新功能公告，也不意味着所有长输入都会导致相同错误。
团队可以先检查一件事：当前任务到底需要哪些字段，工具又返回了多少无关材料。如果读取一条状态却要浏览一整份档案，接口设计就值得调整。目的不是一味节省字数，而是让智能体更容易定位应该判断的对象和对应证据。
第一层结果先回答“找到了什么”
一个建议的返回方式是，先给出记录标识、当前状态、相关时间和简短说明，再明确是否存在更多详情。状态不确定、命中多条记录或结果不完整时，应直接表达出来，不要把这些情况隐藏在一段看似肯定的摘要中。
例如查询可能找到两张相近工单。此时返回候选编号与必要区分字段，比直接选一张并生成长摘要更容易核对。智能体可以继续向用户澄清对象，也可以根据授权范围读取细节。它不应因为工具已经返回文本，就默认对象已经唯一确定。
字段名也要表达业务含义。把创建时间、最后更新时间和真正完成时间分别说明，避免统一塞进一个“时间”字段。接口对开发者看起来简短，如果对智能体形成歧义，反而会增加后续查找和解释的工作。
详情入口要稳定，不能只是“需要时再问一次”
如果摘要无法支持判断，智能体需要继续读取对应证据。建议使用稳定的记录编号、文档位置或查询条件，让下一次读取仍指向同一个对象。若工具只返回一段自由文本，后续检索可能找到相似却不同的记录，很难确认前后依据一致。
读取也应保留当时的版本或时间信息。某条状态在两次调用之间变化时，系统需要说明变化发生了，而不是把不同时间的材料拼成一份静态事实。涉及后续业务动作时，最终判断尤其需要基于适当的新鲜度要求。
权限检查仍然要发生在每次读取时。一个记录出现在摘要里，不意味着该用户就能读取它的全部附件和沟通内容。分层返回是信息组织方法，不是绕过访问控制的办法；具体能读到什么，应继续由业务系统的授权机制决定。
摘要不能替原始结果删掉不方便的细节
设计摘要时，最容易丢掉的是否定、例外和不完整状态。例如“已处理，但客户尚未确认”若被压成“已处理”，后续动作就可能提前结束。团队需要明确哪些字段必须原样保留，哪些文字允许概括，不能把压缩任务完全交给一个笼统提示词。
空值与没有结果也要分别表达。没有查到记录、没有权限查看和系统暂时无法查询，对用户意味着不同的下一步。三种情况若都输出空列表，智能体很容易把技术失败解释成业务事实，并继续给出过度肯定的回答。
可以专门准备一组难以概括的样本：备注推翻状态、附件补充例外、多个时间指向不同阶段。先人工确认这组材料的必要信息，再检查摘要是否保留。若关键信息频繁丢失，应调整返回结构，而不是只要求模型“认真一点”。
分页与截断，也需要让调用者看得见
当查询结果很多时，可以考虑分页或限制返回范围，但应说明本次读到了多少、是否还有剩余，以及怎样继续读取。如果只是无提示地截取前一段，智能体可能把局部结果当成全部记录，进而给出没有根据的完整性结论。
例如用户要求汇总某个周期内的工单，工具只返回首批结果。此时“本页没有未结工单”不能推出“该周期没有未结工单”。接口和提示应帮助调用者识别范围，必要时继续读取；不能让摘要替系统假定后续页面没有重要信息。
还可以准备一个关键记录恰好落在末页的测试案例，观察任务是否会继续查询。若预算或时间不允许读完，就明确给出已检查范围和未完成部分。这个测试关注的是结果覆盖能力，无需把所有历史记录重新塞回单次响应。
验收要比较整个任务，不能只比返回字数
缩短一次工具结果，可能导致后续连续调用很多次。工具设计应观察完整任务的读取次数、总耗时和最终质量，不能只用单次响应大小宣布优化成功。对记录很少的简单任务，直接返回完整必要信息也可能更合适。
测试时可以固定同一组脱敏问题，比较原方案与分层方案能否定位正确记录、能否引用对应依据、能否识别不完整结果。对发生争议的案例，保留实际返回与决策过程，让团队知道问题来自字段设计、读取选择还是最终表达。
一路凯歌建议，从一个返回过长、错误可复现的工具开始改。先让首层结果清楚，再补上稳定的详情入口和例外说明，观察它是否帮助业务任务完成。这样的改动比一次重做整套智能体更容易验证，也更容易让接口维护人员接手。
要点总结
- 不是。应保留完成任务必需的信息，特别是限制条件、异常状态与证据位置，不能单纯追求缩短。
- 可能，因此需要说明摘要覆盖范围，保留稳定的记录标识和继续读取入口，并验证重要信息是否被遗漏。
- 用同一批真实脱敏任务比较信息完整性、引用准确性、读取次数和耗时，不能只看单次输入长度。
参考来源说明
本文为技术解读。来源时间：2025-09-29；2026-10-22重新核对。官方资料用于核对文中对应事实，实践建议为本站分析；假设场景不代表真实客户案例或效果。