律师只想核对合同里的续约条件，助手却要求上传整个客户文件夹。里面还有谈判底稿、其他合同和邮件。一次针对条款的工作，不应该默认从收集全部资料开始。
合同很短时，律师选取条款并保留必要上下文，往往就能完成核对。已有文档系统能按权限搜索并引用原页，也应继续使用。需要跨多个助手反复查询时，再把这种有限读取接成稳定入口。
文档侧可以提供一个查询操作，接受获准合同编号、版本和条款类别，返回必要片段、页码和来源。EasyNet 连接助手与这个操作；接入目录引用本身，并不会自动实现条款识别或法律检索。
服务端核验调用者能否访问该客户和该份合同，凭证留在文档侧。若后续要把片段送给外部模型，应另行确认处理范围与保留政策。运行在自己的设备上，不足以证明整条分析过程没有外传。
文档适配需要处理版本、附件和引用准确性。主合同缺少被引用附件时，助手应请求补充特定资料，不能悄悄扩大到整个文件夹，也不应仅靠缺失的片段给出确定结论；最终解释由负责律师核对。
先用虚构合同验证同名条款、旧版合同和附件缺失，再让无权访问该客户的身份尝试查询。验收重点是能否回到正确原文，以及需要更多材料时是否只提出具体请求，而非把所有文件都收进来。
- 01
律师指定合同
客户、版本与续约条款
- 02
文档侧取片段
返回页码，不开放整库
- 03
补齐引用附件
缺少证据就暂不下结论
找出条款引用但未提供的附件
合成合同结构检查，不解析真实合同、不提供法律判断。
本地示例 · python
clause = {"contract": "demo-C17", "version": 2, "references": ["schedule-B"]}
available_attachments = {"schedule-A"}
missing = sorted(set(clause["references"]) - available_attachments)
assert missing == ["schedule-B"]
print({"request_attachment": missing, "conclusion": "pending"})预期结果：只请求schedule-B，结论保持pending，不扩大读取整个客户文件夹。
接入时的检查项
- 跨客户合同请求被拒绝，错误结果不暴露其他客户的文件存在性。
- 返回条款能在批准版本中定位，缺少附件时明确说明依据不完整。
- 实际输出与日志不包含未获准的谈判记录或整份客户档案。