先理解
刚接触这个知识点
补齐先备概念,读原理与反例,再用自己的话解释为什么。
从核心原理开始 →理解 → 实现 → 排错 → 取舍
把身份、知识权限、结构化工具、持久化任务与审核发布连接成可恢复的系统。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
按当前基础选择起点,也可以依次深入。遇到不熟悉的概念,先回到核心原理;完成后用知识练习检查理解。
LEARN · PRACTICE · REFLECT
先沿着原理、问答和迁移案例阅读。需要检查理解时,再切换巩固练习或展开个人记录。
核心知识 · 证据到发布的受控任务链
先备概念:业务状态机、快照与版本、幂等提交
企业任务应把读取证据、生成草稿和发布效果分别留账,再用版本和授权连接。持久编排能恢复控制流,但不会自动保证证据一致或外部写入只发生一次。
查资料证明使用了哪些版本,草稿证明根据证据生成了什么,发布回执证明外部系统实际接受了什么。若把它们都放进一段对话,恢复时很难区分建议与完成。业务记录应独立保存来源清单、草稿摘要、批准对象和业务发布键。
同一个数据库内可按适当事务隔离读一致快照;跨文档系统和数据库通常没有一个共同全局事务。需要声明按某个截止时间或各自版本取证,检测更新并说明滞后,不能仅因为读取发生在一分钟内就称为原子快照。
批准绑定草稿,发布前重验当前权限和资源条件。outbox 将本地状态与待发布意图原子保存,投递仍可能重复,目标服务需去重或查询。取消阻止未来步骤,不能撤回已提交效果。下面的架构和窗口均为设计推演,没有企业生产验证。
我会先划分读取、生成和发布三个阶段。入口建立可信租户和任务记录,检索与 SQL 工具都执行权限过滤;模型按证据生成带版本的草稿。长任务以状态机推进,检查点与副作用分开,待发布动作写入事务 outbox。人工批准绑定草稿版本,worker 通过幂等键调用发布服务,超时先查结果;最后用审计链路和故障注入验证跨租户隔离、恢复与重复执行。
需求是企业内部报告,不需要让模型自由连接所有系统。入口验证身份,建立 tenant_id、run_id、任务预算和版本。状态可采用 queued、running、waiting_approval、publishing、succeeded、failed、cancelled,转换由后端校验。对话历史是用户交互资料,任务状态才是恢复依据;数据库保存步骤输入摘要、检查点和错误,文档及草稿内容放在受权限保护的存储中。
检索服务先按租户和文档权限限定候选范围,再做排序,返回片段、版本和出处。SQL 工具优先暴露账户余额、流水汇总等确定接口;需要动态查询时,使用只读账号、允许表和查询超时,解析检查不能替代数据库权限。模型将结构化结果与文档证据合成报告,数字计算交给确定代码。未查到数据时明确指出缺口,不能用相近账户补齐。引用附上查询参数和快照时间,敏感参数在用户输出中适当脱敏。
LangGraph 的 Persistence提供检查点等持久化机制,但保存图状态不等于外部操作只发生一次。生成草稿后持久化版本,审批绑定这个版本。数据库事务内同时更新发布意图并写入 outbox,由 worker 投递;这保证本地意图与队列记录一同提交,并不让远端服务与本地数据库处在同一事务。消费者仍可能重复消费。对端支持幂等键时使用稳定 action_id,超时查询结果;不支持时进入待核对状态,避免直接重复发送。
Temporal Activity Execution说明活动可能多次执行,因此业务副作用仍要幂等或明确限制重试。是否引入专门工作流引擎取决于任务时长、恢复要求与团队运维能力,不能只为使用热门框架增加系统。给每个任务设置总步数、token 预算与截止时间,取消时停止新动作,已发出的远端请求需要核对最终状态。验收采用跨租户检索、worker 在发布后崩溃、消息重复投递、审批过期和模型不可用五类场景,检查公开产物、任务状态与审计记录是否相符;这些属于设计测试目标。
可在空 SQLite 数据库运行。示例只演示本地事务写入发布意图,没有实现权限、审批、消费者、对端幂等与版本变更后的恢复。不能据此宣称端到端 exactly-once。 任何语句失败都必须由调用方回滚整个事务;outbox 插入失败后不能继续提交已经更新的报告状态。
PRAGMA foreign_keys = ON;
CREATE TABLE report (
tenant_id TEXT NOT NULL,
report_id TEXT NOT NULL,
version INTEGER NOT NULL,
status TEXT NOT NULL CHECK (status IN ('draft', 'publishing', 'published')),
PRIMARY KEY (tenant_id, report_id)
);
CREATE TABLE publish_outbox (
tenant_id TEXT NOT NULL,
action_id TEXT NOT NULL,
report_id TEXT NOT NULL,
report_version INTEGER NOT NULL,
status TEXT NOT NULL DEFAULT 'pending',
PRIMARY KEY (tenant_id, action_id),
FOREIGN KEY (tenant_id, report_id) REFERENCES report(tenant_id, report_id)
);
INSERT INTO report VALUES ('tenant-a', 'report-1', 3, 'draft');
BEGIN TRANSACTION;
UPDATE report SET status = 'publishing'
WHERE tenant_id = 'tenant-a' AND report_id = 'report-1'
AND version = 3 AND status = 'draft';
INSERT INTO publish_outbox (tenant_id, action_id, report_id, report_version)
SELECT 'tenant-a', 'action-1', report_id, version FROM report
WHERE tenant_id = 'tenant-a' AND report_id = 'report-1'
AND changes() = 1;
COMMIT;
SELECT report_id, report_version, status FROM publish_outbox;
预期输出
report-1|3|pending沿着问题的前提和约束继续向下读。先理解参考解答,再尝试收起答案,用自己的话解释因果和取舍。
第 1 层报告涉及多份不断更新的文档,怎样定义一致的证据快照?
报告有多个动态来源,需解释证据一致性的范围。
保存每份来源的稳定标识、版本、获取时间与引用片段,约定报告截止口径。同库可用一致快照,跨源则记录版本清单并检测更新,必要时重审或提示不同步;无法建立共同快照时诚实说明证据时间边界。
沿着这个回答继续深入
第 2 层审批等待期间其中一份来源更新,必须整份报告重算吗?
父问保存证据版本,子问增加生成与批准之间的来源变化。
按主张到来源的依赖关系判断。若更新影响关键数字或结论,生成新草稿并重批;不相关排版更新可记录判断依据,未必全量重算。不能只比较文件日期,也不能在原草稿里静默换引用后沿用旧批准。
沿着这个回答继续深入
第 3 层来源撤销访问但已保存快照,可以继续发布原报告吗?
父问处理内容更新,继续加入权限撤销而非一般版本更新。
不能仅凭曾经合法读取决定。重新检查存储和外发政策、当前任务权限及撤销目的;必要时隔离快照、删除受影响草稿并重审。保留审计标识不等于保留正文许可,报告发布是新的数据使用动作。
第 1 层发布成功后 worker 崩溃,恢复时怎样避免重复发布?
持久任务恢复遇到外部成功、本地未记的窗口。
沿原发布业务键向目标查回执或重发幂等请求,成功后补本地完成记录。outbox 不保证接收方仅收到一次。若目标既无去重也无法查询,保持未知并人工核对,不能生成新键重发。
第 1 层用户取消任务时,已经发出的外部请求怎么处理?
任务链还需定义取消与不可逆提交之间的关系。
先记录取消意图并停止新增可取消动作,核对在途请求真实结果。已提交的报告发布需按业务下线或更正流程另行处理,不能把本地状态改 cancelled 就认定外部撤销。未知结果仍要对账,补偿也需要授权和回执。
先找出改变的条件,再判断原方案中哪些前提仍成立。下面的案例是教学推演,便于将原理迁移到新问题。
改变的条件:去掉外部发布,用户手动下载审阅。
延伸问题:哪些环节可以简化?
可以不做自动发布 outbox,但读取授权、来源清单、草稿版本和下载权限仍要保留。终态定义为草稿保存并可被授权用户读取;不要把生成成功宣称为正式发布完成。任务范围缩小,不代表所有证据与隔离要求消失。
保持不变的原理:各阶段事实与授权仍须明确,按实际效果定义完成。
改变的条件:来源与权限可能变化,外部目标有重试。
延伸问题:如何维持原批准的含义?
持久保存批准对象与版本,执行时检查有效期、来源影响和当前授权,变化则重提案。原业务键贯穿重试并核对目标;只凭恢复旧检查点不能证明旧动作仍可执行。
保持不变的原理:恢复控制流不能替代当前业务有效性和效果核对。
依据公开技术资料设计;参考资料支持技术机制,场景与评分标准为本站设计,不代表某公司面试原题。 新增问答与迁移案例用于原理讲解,来源核查与案例运行验证分别记录。
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评;需要进一步验证时,再完成下方小任务。
为集团司库的“查询、分析、生成报告、审批发布”画边界和失败路径。