AI Agents
2026 年，多数物业团队在落地 LLM 摘要时，卡住的并不是模型质量，而是同一个任务被第二次、第三次执行。一次本来正确的摘要，会变成重复记录、挂错人的评分说明，或者在一轮上游超时之后自相矛盾的候选人档案。
这个模式的成因很固定：摘要接口一天就能接完，演示效果很好，然后重试逻辑——通常是仓库里最少被 review 的那个文件——悄悄决定了业务方对一个租户、一张工单、一位申请人的判断。
这份清单面向负责物业场景摘要流水线的技术负责人与增长运营：按评分标准筛选申请人、维修工单分级、租约摘要生成、供应商比选。每一项都有明确的通过／不通过判据，按顺序推进即可，前面的项会约束后面的项。
统领原则：按失败成本路由，而不是按 token 价格
图示：来源页预览图（仅作编辑上下文；版权归属原发布方） · 来源引用：dev.to
在讨论任何技术项之前，先定下路由哲学。团队常常从最便宜的对话模型起步，因为单价最容易向上汇报。这个顺序是反的。
先按「输出错误的代价」给你的摘要任务排序。一段措辞笨拙的日常维修摘要，代价是人工多看几秒；一段评分错误的申请人摘要一旦成为拒绝理由，代价就高得多，而且被人读过之后很难撤回。租约条款摘要介于两者之间，取决于后面是否还有法务复核环节。
排序完成后，架构自然浮现：常规层用成本友好的对话模型，放在一个可重试、幂等的 worker 后面；任何模糊情形，走升级路径到更强的模型或人工复核。升级路径不是故障模式，它就是设计本身。
检查清单
1. 摘要契约以带版本的 schema 存在
你的 worker 应该依赖一份小而明确的契约，而不是上游 SDK 的响应结构。输入字段、输出字段、允许的枚举值、摘要最大长度，统一定义并版本化。
通过： 校验器会拒绝任何不符合 schema 的模型响应，且每条存储的摘要都记录了 schema 版本。
不通过： worker 直接读 response.choices[0].message.content，然后祈祷 JSON 能解析成功。
2. 每一次写入都带稳定的幂等键
幂等键应由业务身份派生，而不是请求时间或随机 UUID——例如申请人 ID + 评分标准版本 + 摘要类型。重试必须产出同一个键。
通过： 同一个逻辑任务重放一百次，只产生一条存储记录，而且这个约束由存储层强制，而不是靠应用层自查。
不通过： 键里带时间戳，重试产生大量近似重复行，最后靠人工去对账。
3. 重试有上限、有抖动、有分类
并非所有错误都值得重试。限流和上游瞬时故障值得；schema 违规和内容策略拒绝不值得。对确定性失败反复重试，只会烧预算并推迟升级。
通过： worker 区分可重试与终态错误，使用带抖动的指数退避，限制总尝试次数，并记录终态原因。
不通过： 一个固定 sleep 的 for 循环，或者校验错误也触发重试。
4. 截止时间贯穿整条调用链
一份在它本该影响的决策之后才到达的摘要，比没有摘要更糟——它制造了尽责的表象，却没有尽责的实质。
通过： worker 从调用方接收绝对截止时间，向下传递给模型调用一个派生超时，预算耗尽时干净地放弃任务。
不通过： 使用 SDK 默认超时，而这个超时比它要支撑的人工复核窗口还长。
5. 模糊性有可计算的触发条件
在 prompt 里、在代码里，都要定义什么叫「模糊」。置信区间、缺失证据标记、落在两个阈值之间的评分——选一种，并让它机器可读。
通过： 输出 schema 里包含显式的升级信号，路由器自动遵循，不需要第二道人为判断。
不通过： 升级发生在某位工程师碰巧在看板上发现异常的时候。
6. 摘要引用它所依据的证据
一段断言「维修记录良好」却不指出支撑字段的摘要，不可审计，也扛不住争议。
通过： 输出中的每一项实质结论都映射到被引用的输入字段或文档片段，且引用关系被持久化。
不通过： 纯自由文本，没有出处，逼着复核人重读整份源文件。
7. 检索索引只在持久化写入之后发生
这是最多团队踩错的地方。在事务写入提交之前就把摘要向量化进向量库，会制造一类「搜得到、但系统记录里没有」的文档。
图示：HEXOPS 原创配图（受选题启发，非复制原文图片） · 来源引用：dev.to
通过： 索引更新是「已提交写入事件」的下游消费者，且自身也是幂等的，重放不会产生重复分块。
不通过： worker 在同一个函数体里既调 embedding API 又写数据库，没有任何顺序保证。
8. Prompt 与评分标准被固定版本、可 diff
半年前给某位申请人打分的评分标准必须能被还原，否则分数毫无意义。
通过： prompt 模板与评分标准定义存放在版本控制中，存储输出里记录其哈希，变更需要评审。
不通过： prompt 在后台面板里随手改，没有历史，导致没人能解释一个历史决策。
9. 存在固定评测集与漂移信号
常规摘要的质量是悄悄漂移的。模型升级、prompt 改动、输入分布变化，都会在没有任何报错的情况下移动质量水位。
通过： 每次 prompt 或模型变更都跑一遍有标注的评测集，并按周期抽样人工复核线上输出。
不通过： 质量由「最后一个看过输出的人」来判断。
10. 把「每条被采纳摘要的成本」当作指标
token 单价不是关键数字。重试、升级、人工复核时间都应该进同一个分子。
通过： 你能说出每一层任务「一条被采纳摘要」的全负载成本，并与它所替代的人工基线对比。
不通过： 你只能报出一个「每百万 token 单价」。
关键要点
- 决定哪个模型处理哪类任务的，应该是失败成本而不是 token 价格；通向更强模型或人工的升级路径是设计的一部分，不是缺陷。
- 由业务身份派生的幂等键，是可重试摘要 worker 中杠杆最高的单一防护；下游一切都依赖它。
- 重试必须分类。对 schema 违规和策略拒绝反复重试，既浪费预算又掩盖真问题。
- 在持久化写入提交之前就把摘要写进检索，是这类流水线中最常见的结构性 bug。
- prompt 与评分标准是你的审计链的一部分。它们不版本化，你的历史评分就不可辩护。
下一步
- 拿上面十项给你的现有流水线打分，逐项标注通过／不通过——不要给「部分通过」。
- 优先修第 2、3、7 项，它们造成的问题最难挽回。
- 在下一次模型变更之前，把模糊性升级阈值写下来，而不是之后。
- 采集「每条被采纳摘要的成本」，并与人工基线放在同一个看板上。
- 建立季度重放测试：把一批历史任务跑过当前流水线，与当时存储的输出做 diff。
