先记住这个答案
结构化 schema 保留字段关系、数值精度和可追踪性，自然语言摘要可能丢失字段、错误合并或引入幻觉。优先使用 JSON 等结构化格式交接，在协议中定义必填字段和版本；仅当接收方为纯 LLM 且需要语义理解时，附上摘要作为辅助，但原始数据必须保留供校验。
- 结构化 schema 交接保留字段与精度
- 自然语言摘要只作辅助，不可替代原始数据
- 交接协议需定义版本与校验机制
为什么自然语言摘要会丢信息
结构化数据有固定 schema，字段名、类型、嵌套关系都可以被下游校验和过滤；而 LLM 生成的摘要可能丢失字段值、数值精度或表格的行列对应，甚至引入编造内容。例如 JSON 中的 price: 19.99 在摘要里可能变成“约 20 元”，语义相近但无法精确计算。
结构化结果还携带状态和元数据，如任务 ID、置信度、错误码。摘要通常按“重点”挑选，这类控制信息难以被自然语言完整携带。当交接链变长，每次摘要重新生成都会累积误差，被漏掉的字段无法被察觉，最终下游只能依据一个模糊的转述做判断。
电商客服多 Agent 退款链路
输入用户请求“退货”，意图分类 Agent 输出 {"action":"refund","order_id":"A123","reason":"damaged","confidence":0.92}。若交给一个 LLM 把结果改写成“用户要求退款，订单 A123，原因是破损，置信度较高”传给退款 Agent，退款 Agent 需要判断是否可自动放行，但摘要里没有精确的 confidence 数值，无法通过与 0.9 阈值的比较。
处理方式是让交接协议直接传原始 JSON，退款 Agent 读取字段并执行规则：confidence > 0.9 时自动退款，否则转人工。即使某些下游需要语义理解，也把摘要放在 summary 字段，但核心决策只依赖 raw_data完整对象，防止信息降级。
哪些场景可以接受摘要
当接收方不是程序化处理，而是给人阅读的展示层，或仅用于低风险参考时，摘要可接受。但若下游需要数组长度、数值区间、精确日期或枚举值，就必须保留原始数字字段，不能只写“下周”或“大概”。否则系统在用户退款金额上出现偏差就是事故。
此外，如果交接双方没有强制 schema 或没有做入参校验，那摘要只会让掩盖问题更容易。正确做法是每个 Agent 声明输入输出 schema，并在运行时校验；摘要只能作为调试或人审的附注，绝不参与程序分支判断。若必须全用自然语言，需要额外用库或模型把关键实体抽取回结构化字段，但这种方法仍有准确率上限，不能作为默认可靠方案。
容易答错的地方
- LLM生成的摘要对LLM也够用
- 即使下游也是 LLM，摘要可能丢失枚举值、数值和关联 ID，且无法追溯。比如结构里的
status: "pending_payment"被概括成“处理中”，可能让后续 Agent 误判为“待发货”。错误会随链路累积，准确率逐级下降。正确法是传原始 JSON，让每个 Agent 自己提取需要的字段。 - 把JSON.stringify当成结构化
- 无 schema 的 JSON 一样会产生字段名歧义、类型漂移。例如 A 写
customer_name，B 读user_name，解析必失败。结构化的核心是契约：需要定义字段类型、必填项、枚举值，并生成校验代码在运行时报错。没有契约的 JSON 只是格式不同，仍然有损。
面试官还会怎么问？
如何判断交接消息是否满足无丢标准？
用类型校验与合约测试：接收 Agent 按 schema 解析失败应立即报错；同时统计摘要覆盖原文的字段比率，对数值、ID、枚举类字段覆盖率未达 100% 的单测应视为未通过。关键字段必须在 schema 中标记为 required 且不可省略。
如果产物需要给非技术用户看，是否必须用自然语言？
可以由表现层负责将结构化结果渲染成自然语言模板，但这份摘要不参与另一端 Agent 的输入。若必须传，应在协议里额外携带 structured_origin 字段，保留原始 JSON 供核查。不要让接收 Agent 依赖自然语言转述。
在 LangGraph 中如何用共享 state 实现无丢交接？
用共享 state 存结构化 payload，Agent 从 state 读取所需字段并把结果写回，避免摘要传递。若需要 LLM 处理，让 LLM 从 state 中取必要字段，完成后再返回结构化的增量，而不是先输出自然语言再由下游“解读”。这样每个 Agent 的写入都经过 schema 校验。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。