不要把“AI 连上 ERP”理解为“一次把所有命中记录交给模型”。先限定业务范围，再为业务查询定义分页、排序、完整性、权限和续查规则。MCP 的标准分页主要处理工具、资源等列表发现；它不会自动替 ERP 订单查询切页。
近期观察：工作台任务能力在增强，业务数据范围仍要单独设计
截至 2026 年 10 月 18 日，过去 24 小时未发现 WorkBuddy、千问办公或豆包工作重大版本发布。72 小时内可核实的近期动态包括：WorkBuddy 5.8.2 于 10 月 16 日发布，包含历史会话和文件交付等问题修复；千问办公 1.3.1 于 10 月 15 日发布，更新任务执行引擎并增加电商经营模式及配套连接器。官方日志没有说明这些改动会自动为企业 ERP 明细查询提供分页、筛选或数据完整性保障。WorkBuddy 官方更新日志；千问办公客户端更新日志。因此本文按近期观察撰写，不把旧版本动态包装为今日发布新闻。
这项设计在三类场景尤其重要：查询历史订单、核对跨仓库存流水、汇总某个时间段内的业务明细。即使底层接口响应成功，如果结果被服务端上限截断、连接器只取第一页，或排序在翻页期间发生变化，AI 仍可能拿到不完整的集合并生成看似确定的结论。
一次返回全部记录，会带来哪些实际问题？
- 结果不完整却没有提示：接口或运行环境达到响应大小限制，只返回部分行，摘要仍被描述为“全部订单”。
- 耗时与资源不可控：大查询占用数据库、网络、连接器和工作台上下文，拖慢其他任务。
- 跨页口径不稳定：翻页期间新记录插入或旧记录更新，使用不稳定排序时可能跳过或重复记录。
- 权限范围扩大：一次请求包含员工完成任务并不需要的部门、时间段或敏感字段。
- 结论无法复核：回答没有保留筛选条件、统计时点、总量和已读取范围，业务人员难以重现结果。
MCP 的分页解决什么，不解决什么？
MCP SDK 文档列出的 cursor 分页面向 tools/list、resources/list、prompts/list 等协议列表操作：服务端返回一页和可选的 nextCursor，客户端再带回游标继续读取。它主要用于发现和列举服务器提供的工具、资源与提示。MCP Python SDK：Pagination；MCP C# SDK：Pagination。
ERP 订单查询通常是一次 tools/call：模型调用一个业务工具，工具再向 ERP 查询行记录。协议不会自动知道订单时间范围、页大小、稳定排序或“是否还有下一页”。这些需要业务工具输入输出契约和目标系统接口明确支持。若接口一次性返回整批数据，工具端仍需控制查询范围、结果大小，并明确给出是否完整；不能仅因连接方式采用 MCP，就默认得到了业务查询分页。
另一个细节是“完整集合”的含义：工具可能成功返回了第一页，但这不等于业务查询已完整。输出应明确标注 complete、partial 或 hasMore 等业务状态，并说明它们对应的正式字段；这些名称是设计示例，不是 MCP 标准字段。
给 ERP 查询工具定义六项结果契约
1. 先把筛选范围写成必填条件
围绕业务问题限定日期区间、组织或仓库、单据状态、客户或物料等条件。对“最近订单”“异常库存”这类模糊请求，先澄清统计周期和对象范围，再生成调用参数。给查询设合理的最大范围和结果上限，超出上限时要求进一步筛选或使用受控导出流程。
2. 明确排序和分页单位
定义稳定且可复现的排序，例如业务时间加唯一单据主键，避免仅按可能相同的日期排序。优先使用目标系统支持的游标或 continuation token；如果只能使用 offset / limit，要评估数据变化时的跳行、重复与性能问题，并用实际接口测试确认。游标应由服务端生成，客户端按契约原样传递。
3. 让每页都继承相同权限和过滤
后续页不能绕过首次查询的员工身份、组织授权和 ERP 原权限。游标应绑定原始查询参数与必要的主体上下文，并考虑过期和授权变化；不可把一个人的游标直接拿给另一位员工继续读取。权限或筛选变化后，应重新发起查询。
4. 返回结果覆盖范围和完整性
每次响应至少说明当前页记录数、是否还有后续页、适用筛选条件、数据更新时间或查询时点；若目标系统提供准确总数，可附总量及计数口径。超过限制时明确返回部分结果，不要把静默截断伪装成完整结果。模型据此只对实际覆盖范围做结论。
5. 限制字段并优先聚合
先让业务系统执行筛选、排序、分组和聚合，把“每个客户的订单数量和金额”作为汇总结果返回；只有业务人员需要追查时，再按组展开明细页。按任务只返回必要字段，敏感字段遵循授权与展示规则。把计算留在数据库或 API 侧，避免将数万行原始数据塞进一次模型上下文。
6. 说明翻页期间的数据一致性
如果报表要求精确对账，确认目标系统是否能按同一快照、导出批次或查询时间点读取所有页；如果只是运营观察，也应说明分页期间数据可能更新。无快照能力时，可带上时间边界和唯一排序键，完成后对总量或关键聚合做复核。
从小样本到大结果集的验收清单
- 准备边界数据：包括空结果、刚好一页、超过一页、上限之外、相同排序时间戳和查询期间有新增或更新的记录。
- 核对页间连续性：比较源系统和分页结果的首尾标识，检查重复行、漏行、排序稳定和游标过期行为。
- 验证身份边界：让不同权限员工调用同一查询，确认每页都按目标系统原权限返回；更换用户、组织或授权后测试旧游标是否会被拒绝。
- 模拟中断：在翻页请求中断后恢复，确认继续点不会悄悄跳页或重复计数；任务重启时根据查询契约重新核对数据范围。
- 检查回答标注：结果不完整时，模型必须说清部分范围和限制；汇总数字应能由同一筛选条件下的源系统数据复核。
- 记录资源成本：比较最大行数、响应大小、查询时延和上下文占用，按系统承载能力设置阈值，而不是统一套用某个固定页大小。
一份能用于运维的验收记录，至少保留查询条件、当前员工、目标系统、返回记录数、完整性状态、查询时点、续查次数和异常结果。具体日志字段以系统实际提供为准，不要假设 AI 对话文本本身足以还原数据范围。
星云 PLUS 如何参与业务查询治理
星云 PLUS AI 系统连接器可按项目条件复用企业既有数据库 / SQL、RESTful API、业务页面、Skill 或 Agent，将业务能力发布给 AI 使用。已确认的产品事实包括按员工、用户组或组织授权，连接目标系统时使用员工个人账号，并由目标系统原权限判断其能访问的数据和功能；调用审计支持按员工、系统、能力、时间和执行结果查询。
卖点库与产品事实确认表没有把通用业务数据分页、固定结果上限或一致性快照列为星云 PLUS 的标准功能，所以本文不作此类承诺。项目设计时应根据具体 ERP/API 的能力定义查询契约、分页和完整性策略，再在目标环境联调。先选一个明确范围的只读查询，用源系统结果验证口径、权限、覆盖范围与异常处理，再决定是否扩展到更多场景。
先从范围明确的业务查询开始
如果企业正在评估如何让 AI 使用 ERP、CRM、MES、WMS 或 OA 中的真实业务数据，可访问星云 PLUS 官网了解 AI 系统连接器，并关注视频号“星云AI开发平台”获取实践内容。
了解 AI 系统连接器资料来源与核验日期
- WorkBuddy 官方更新日志：版本 5.8.2 发布于 2026-10-16。查看更新日志
- 千问办公客户端官方更新日志：版本 1.3.1 发布于 2026-10-15。查看更新日志
- MCP Python SDK 文档：Pagination。查看说明
- MCP C# SDK v2 文档：Pagination。查看说明
- 产品事实：只读核对指定《09-星云PLUS产品营销卖点库》，并以官网《星云 PLUS AI 系统连接器产品事实确认表》核验；没有将分页或固定结果限制写成已确认产品能力。
公开来源核验日期：2026-10-18。MCP SDK 文档为滚动维护页面，本文仅引用其当前分页语义，未将页面内容称为近期发布。
常见问题
MCP 自带分页，业务查询工具就不用设计分页了吗？
不是。MCP 的标准 cursor 分页适用于 tools/list、resources/list 等协议列表操作。通过 tools/call 查询 ERP 订单、库存或流水时，业务结果的筛选、分页和完整性仍需由具体工具与目标系统接口定义。
AI 查询结果被截断后，可以让模型根据已有数据推算总量吗？
不可以。应返回实际筛选条件、结果数量、是否完整、统计口径和可继续查询标记。没有完整性证据时，不应把已返回部分当作全量数据做合计或趋势结论。
业务数据分页应该选 offset 还是 cursor？
取决于目标系统、排序稳定性、数据变化速度和接口能力。关键是有确定排序、明确游标作用域，并处理翻页期间新增或变更记录；具体选择应以系统条件和联调测试为准。
分页会不会导致 AI 漏看记录？
有可能，尤其在游标错误、排序不稳定、权限变化或数据持续更新时。应核对页间重复与缺失、首末边界、筛选条件继承和总量，并让汇总标明数据时间与覆盖范围。