endorphin-tabularium-docs/content/docs/07-composable-judgments-draft.md

LangGraph、DSPy 与可接续的判断对象

记录日期：2026 年 10 月 28 日。本文从Agent 编程的三个问题继续讨论：已有探索为什么有价值，边界在哪里，以及 Endor 可以验证什么。

研究与设计草案：官方机制、本文的分析和候选设计在各节中区分。下文没有确认新语言语法、对象内置类型或权限规范；没有修改现有 271 项语言设计议题的确认状态，也没有实现运行时功能。资料按本文日期查阅，具体 API 会演进。

两条路线分别解决了什么

LangGraph 把状态、节点和转移显式组织起来；DSPy 把模型任务表示为签名和模块，并根据指标优化程序。它们分别使执行过程更可管理、模型行为更可测量。它们也可以组合使用，并不是相互排斥的完整替代品。

维度	LangGraph	DSPy	本文进一步提出的问题
组织单位	状态、节点、边与子图	任务签名、模块与模型程序	一项判断能否跨流程保留身份、依据与适用范围
关键进步	显式组织路径、状态与恢复	分离任务声明、调用策略与优化	如何接纳、复用及作废一个结果
可获得的检查	图结构、状态约束、应用代码检查	输出结构、约束验证、数据集上的指标	证据版本、权限、业务条件与变化后的复核
不会自动成立的事情	节点执行过不代表业务判断正确	得分提高不代表每次都满足真实需求	有来源也不代表内容真实或推理正确

LangGraph 为什么好

从聊天历史走向明确的执行状态

官方 Graph API 把工作流组织为 State、Nodes 和 Edges，并用 reducer 规定更新怎样合入状态。它还支持输入、输出及内部状态的不同组织方式。这让开发者可以明确决定数据传到哪里，而不必把所有东西拼接成一段聊天。Graph API

其价值是把一部分程序结构从模型的临时理解中拿回来：例如审核节点产生的允许集合，由普通代码选择后再提供给写作节点。

让中断与长期工作可以被管理

checkpointer 保存线程的图状态，store 保存跨线程数据；持久化实现的选择决定重启后是否还能接续。interrupt 支持等待外部输入，恢复时可能重新执行节点开头的代码，因此调用者必须处理重入和副作用。Persistence、Interrupts

这是真实的执行能力，不只是“请记住进度”的指导。它让人可以在工作中间介入，而不必完全重开任务。

保留动态决策空间

LangGraph 有条件转移、动态路由和子图，节点里也可以包含开放式 Agent。不能把它批评成“只能预先画死全部步骤”。其强项在于让确定性逻辑和模型判断出现在一个可组织的执行过程里。Graph API 的 Command

LangGraph 为什么还没有回答完这个问题

以下是对职责边界的分析，并不是说 LangGraph 无法用应用代码实现这些能力。

流程状态不自动等于业务世界的有效状态。 checkpoint 可以保存“审核完成”，但被审核文件之后可能已经修改，或者用户已经撤回了授权。恢复执行时是否重读、复核和拒绝过期结果，需要应用定义。

状态结构不自动等于信息安全边界。 节点输入过滤有实际价值，但不能仅凭字段叫 private 就假设它不会进入日志、流输出或其他路径；数据访问、工具访问和输出通道仍需检查。一个图也可以做严格隔离，只是隔离不能由图形名称推导。

检查节点不能天然证明上游结论。 模型审核也可能犯错，与生成者共享偏差。增加一个 reviewer 节点是一种策略，实际效果要用独立样例和人工核验评估。

跨任务的判断复用需要共同约定。 两张图都产生“供应商通过审核”，是否针对同一公司、同一资料版本、同一政策和时间范围？这些业务关系可以加入 state 和数据库，但各应用往往还需自行定义。

因此，应继续利用图的执行能力，同时把跨流程可用的结果关系设计清楚。新做一个流程编辑器，未必解决这些问题。

DSPy 为什么好

把任务声明与求解策略分开

Signature 声明输入、输出及任务意图；Module 组织调用策略。同一任务可以更换求解方式而保留接口。这让“我们要什么结果”和“模型如何尝试完成”更容易分别修改。Signatures in depth

例如，可以把证据列表到候选结论表示为一个模块，在相同输入集上比较不同策略，而不必重写整个应用。

让改进从手调措辞走向可测量的优化

DSPy 的优化器接受程序、指标和样例，根据反馈调整指令、示例，某些优化路径还涉及模型权重。这让提示词成为可优化的实现，而不是只能凭直觉维护的字符串。DSPy 优化器官方文档源码

真正值得借鉴的是对“好不好”的显式追问：必须给出数据和评估方法，才能比较优化前后的程序。

DSPy 为什么还没有回答完这个问题

结构类型和业务成立条件不同。 输出符合字段与类型要求，不说明结论受证据支持。“供应商可靠”可以是合法字符串，却没有包含可靠性的范围、依据和时效。增加业务字段有帮助，字段内容仍需要检验。

指标是目标的可测量代理。 如果只奖励引用数量，系统可能更愿意多加引用，而没有提高引用的支持程度。需要分别评估正确性、覆盖、证据支持、拒答、成本和耗时，并使用独立保留样本，避免只追逐一个总分。

离线优化与在线条件之间存在距离。 真实对象会变化，工具可能失败，权限可能收回，用户目标也会调整。验证集上的改进不能自动替代每次行动前的状态与授权检查。

换模型后的可替换性仍需验证。 接口兼容不等于行为兼容；优化产物需要连同模型配置、数据集与评估记录版本化。更强模型可能减少某些提示策略的必要性，也可能改变结果分布。

这些并不削弱 DSPy 的价值。它提供了进行比较和优化的机制；把它当作业务真理的证明器，才是越过了其能力边界。

我们可以补上的一层：让判断成为可接续的对象

候选方向是让 Agent 产出的判断，成为后续程序可以检查、组合和更新的工作对象。重点不在新的提示词容器，而在输出被其他任务使用时仍保留必要关系。

一项判断可以包含以下信息。字段仅用于原型讨论，不是已确认的内置类型。

信息	例子	能检查什么
主张与范围	供应商 A 满足本次采购的材料要求	区分不同问题，避免把局部结论扩成全面认可
输入对象及版本	营业文件 v3、报价单 v8	判断产生时实际使用了哪些材料
证据关联	某项要求对应文件的哪些位置	引用是否存在，是否为允许使用的材料
判断性质	原文摘录、计算结果、推断、人工确认	不把不同可靠性来源压成一个字符串
生成与检查记录	模型配置、程序版本、检查规则与结果	复核、模型替换和实验追溯
适用条件	政策版本、对象版本、复核期限	条件变化时识别需要重新检查的结果
后续使用关系	报告段落、采购建议、候选任务	沿已记录依赖定位可能受影响的工作

这里的“可接纳”始终相对于明确政策与检查过程，不命名为无条件的“已证实事实”。模型自报的置信度也不能当作校准后的正确率。

把研究、提案与真实修改分开

模型可以自主探索、重试和比较方案，但先在隔离的候选工作区里产生结果与变更意图。准备提交时，由运行环境检查材料版本、当前授权、接纳条件和影响范围，再实际调用修改能力。

候选工作区可以采用写时复制、事件记录或暂存对象实现，选型尚未确定。它不是整个互联网的快照，也不能回滚已经发出的邮件或外部付款。外部读取可能计费或写日志，也应纳入效果清单；无法模拟的动作需要单独定义提交方式。

一个更有吸引力的体验：修改依据，工作能够局部更新

把前文的 A 查资料、B 审核、C 写报告，继续推进到一个用户可感知的场景：

1. AI 用三份资料形成报告，每个需要依据的结论关联具体来源版本。
2. 用户发现第二份资料有误，将其从本次允许集合移除。
3. 系统沿记录的依赖标出相关结论、报告段落和待提交任务；旧结果保留为历史，但不再作为当前有效依据。
4. Agent 可以寻找替代证据、缩小结论或报告材料不足；与这份资料无关且仍满足条件的结果可以复用。
5. 用户看到需要复核的内容、新旧结论和候选变更，确认后再更新正式对象。

用户感知到的变化是：改一份依据，就能知道哪些判断需要复核，并接着完成这些工作。 对开发者而言，可复用单元从一段生成文本，变成带输入、条件和检查记录的判断过程。

这借用了电子表格重算、增量构建、数据血缘和版本控制的成熟思想，不声称发明了依赖跟踪。需要验证的新价值是：这些关系能否在用户、模型与不同流程之间共同使用，减少每个应用手写一套更新逻辑的成本。

必须承认的限制

• 系统只能沿已记录的依赖传播失效，不能自动理解并发现全部语义影响。模型偷偷使用了未记录输入时，依赖图会不完整；原型应限制数据入口并记录读取，必要时保守地复核整个产物。
• “读取过”不等于“真正依赖”。粗粒度跟踪可能重算过多，细粒度声明可能漏记，需要衡量漏失效与过度失效。
• 版本变化只说明旧条件不再完全匹配，不代表旧结论必然错误。应标为待复核，而不是宣称系统已发现事实错误。
• 重算不保证得到相同结果。回放历史记录与重新调用模型是两回事，外部服务和模型行为也可能变化。
• 本地候选分支可丢弃，不等于全部业务效果可撤销。跨系统提交需要各自支持版本检查、幂等或补偿，否则必须暴露部分完成状态。

怎样形成真正的组合边界

下面的概念接口只表达职责，不是 Endor 已有或拟定语法，也不是可运行代码。

查找(问题, 允许的数据源) -> 资料引用与版本 | 材料不足
审核(资料, 问题, 审核政策) -> 本次允许的证据集合 | 需要人工判断
生成(问题, 允许的证据集合) -> 候选结论与证据关联
接纳(候选结论, 检查政策) -> 接纳记录 | 拒绝原因 | 无法确定
准备(接纳记录, 目标对象版本) -> 候选变更
提交(候选变更, 当前授权, 版本前置条件) -> 实际效果记录 | 冲突 | 部分完成

这些阶段不要求固定成六次模型调用；查找与生成可以动态循环，审核也可以由确定性规则、模型和人工共同完成。受限的是数据与效果边界，解题路径仍可自主选择。

“接纳记录”不能只是让模型在 JSON 中填写 accepted: true。原型可让受信任的检查服务生成记录，并在每次使用时验证记录所属项目、对象版本、政策与有效期。它能证明检查过程发生过，不能证明自然语言结论永远正确。权限应沿用项目既有授权体系，不能通过候选结果自动扩大。

与 Endor 对象模型怎样衔接

这项提案与Endor 的对象操作定位有连接点：材料、判断、候选变更、任务可以保留独立身份和关系，而不只存在于某个聊天上下文或图执行记录中。

候选职责划分如下，仍需逐项设计和确认：

层次	候选职责	不应声称自动完成的事情
语言与类型	表达输入、结果分支、对象引用和可调用能力	仅靠类型名证明自然语言主张
对象与存储	保存身份、版本、关系和历史	自动发现所有语义依赖
运行环境	限制效果、检查当前授权与提交前置条件	跨任意外部系统提供统一事务
模型与模块	解释目标、探索方案、生成候选判断	自行授予权限或给自己签发可信结论
检查与人	定义接纳条件、核验内容、处理不能确定的情况	用一次总分覆盖全部业务风险

先用现有语言和接口验证这些机制，再决定哪些值得进入 Endor 语言。不要先把假设写成语法，再用语法存在证明系统有价值。

最小原型与公平比较

第一版只选“资料到报告，依据撤回后继续修订”这一条工作流。使用有限的版本化资料集和一个可检查版本的报告存储，不接真实付款或邮件，也不扩展成万能 Agent 平台。

对照组采用认真实现的 LangGraph + DSPy 应用，允许它使用显式输入过滤、持久化、同样的检查器及自定义依赖记录；实验组使用相同模型、材料、预算和检查政策，增加可复用的判断对象与依赖处理层。对照组也能实现相同行为，比较重点是重复代码、集成工作量和变更后的可靠性，而不是把对照组故意降成一个长提示词。

实验	需要观察的结果
撤回一份材料	下游是否还有引用被撤回依据的当前有效结果；受影响项是否漏标
修改材料中的一个事实	哪些产物需要复核，哪些可以复用；是否产生过度失效
模型替换	固定任务上的质量、拒答、成本与耗时怎样变化；既有检查能否复用
中断与重试	是否继续正确任务，重复提交是否被目标端拒绝或去重
提交前版本变化	是否报告冲突或重新验证，避免覆盖用户新修改
收回写权限	接续任务是否重新检查并拒绝写入；历史审批不能覆盖当前授权
来源不支持结论	结构检查能否通过，独立内容审核能否识别错误；如实记录漏检
增加第二个工作流	需要重复编写多少字段、失效传播、权限和接纳逻辑

先保存基线数据，再预先确定可接受门槛和独立评估集，不凭最顺利的演示设定标准。分别记录内容质量、来源支持、失效覆盖、过度重算、人工介入、模型与工具成本、延迟和开发工作量；不要把它们合成一个无法解释的“智能分数”。

原型如果不能降低第二条工作流的实现成本，或只是增加很多对象却没有减少错误和复核负担，就说明这层抽象还没有证明价值。如果 LangGraph + DSPy 的直接实现已经足够清晰，则优先沉淀薄库和约定，不必新造完整运行时。

当前建议

保留 LangGraph 对执行的组织能力、DSPy 对模型程序的优化能力；探索让判断的依据、适用条件和后续影响成为共同的对象关系。

最值得做的演示不是更多 Agent 同时对话，而是用户修改一份依据后，系统解释哪些工作受到影响、哪些仍可复用，并让 AI 在受约束的空间里继续完成修订。这项体验能否用更少的应用专用代码实现，才是继续投入的依据。