AFAgent Field Notes会员账号
知识目录选择核心方向与细分内容
Q53高级场景设计约 20 分钟

证据到发布的受控任务链

设计一个企业 Agent:查资料、查数据库、生成报告并由人工批准发布

把身份、知识权限、结构化工具、持久化任务与审核发布连接成可恢复的系统。

系统设计RAG+SQL持久化Outbox

知识内容核对 2026-10-03 · 原题来源核对 2026-10-02

本题目录

READ · UNDERSTAND · TRANSFER

阅读理解,按需巩固

我的笔记与复习 ↗

先沿着原理、问答和迁移案例阅读。需要检查理解时,再切换巩固练习或展开个人记录。

作答与个人记录

每次修改后的提交会保留为独立历史。掌握程度由你对照标准自评。

核心知识 · 证据到发布的受控任务链

先理解核心原理

先备概念:业务状态机、快照与版本、幂等提交

企业任务应把读取证据、生成草稿和发布效果分别留账,再用版本和授权连接。持久编排能恢复控制流,但不会自动保证证据一致或外部写入只发生一次。

一条链里有三种事实

查资料证明使用了哪些版本,草稿证明根据证据生成了什么,发布回执证明外部系统实际接受了什么。若把它们都放进一段对话,恢复时很难区分建议与完成。业务记录应独立保存来源清单、草稿摘要、批准对象和业务发布键。

一致性先有定义

同一个数据库内可按适当事务隔离读一致快照;跨文档系统和数据库通常没有一个共同全局事务。需要声明按某个截止时间或各自版本取证,检测更新并说明滞后,不能仅因为读取发生在一分钟内就称为原子快照。

从批准到效果仍有窗口

批准绑定草稿,发布前重验当前权限和资源条件。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:本地发布意图与 outbox 同事务

可在空 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

工程推演

场景
假设工程场景:资金管理部门要求报告同时引用制度文档与账户流水,并在主管确认后发布。
设计决策
读取接口执行租户权限,数字由确定程序计算,报告和发布审批均绑定版本。
验证目标
目标是每个数字可回放、未批准稿件不可发布、重复消息不产生额外业务动作;尚未作为真实企业效果验证。
适用边界
样例 outbox 仅覆盖本地事务,对端一致性依赖幂等接口或结果核对。

连续追问与解答

沿着问题的前提和约束继续向下读。先理解参考解答,再尝试收起答案,用自己的话解释因果和取舍。

举一反三:条件变了,怎样推导?

先找出改变的条件,再判断原方案中哪些前提仍成立。下面的案例是教学推演,便于将原理迁移到新问题。

只生成内部草稿

改变的条件:去掉外部发布,用户手动下载审阅。

延伸问题:哪些环节可以简化?

推导与参考解答

可以不做自动发布 outbox,但读取授权、来源清单、草稿版本和下载权限仍要保留。终态定义为草稿保存并可被授权用户读取;不要把生成成功宣称为正式发布完成。任务范围缩小,不代表所有证据与隔离要求消失。

保持不变的原理:各阶段事实与授权仍须明确,按实际效果定义完成。

跨天自动发布

改变的条件:来源与权限可能变化,外部目标有重试。

延伸问题:如何维持原批准的含义?

推导与参考解答

持久保存批准对象与版本,执行时检查有效期、来源影响和当前授权,变化则重提案。原业务键贯穿重试并核对目标;只凭恢复旧检查点不能证明旧动作仍可执行。

保持不变的原理:恢复控制流不能替代当前业务有效性和效果核对。

易错点

  • 把向量相似度过滤当作权限隔离。
  • 认为保存 checkpoint 就能自动保证外部写入一次。
  • 将外部服务超时都视为失败并无条件重试。

参考资料

依据公开技术资料设计;参考资料支持技术机制,场景与评分标准为本站设计,不代表某公司面试原题。 新增问答与迁移案例用于原理讲解,来源核查与案例运行验证分别记录。

检查自己理解到哪一步

读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评;需要进一步验证时,再完成下方小任务。

基础达标
能拆出检索、查询、生成与审批发布。
中高级信号
明确数据权限、口径、持久化和工具回执。
资深信号
给出容量、成本、故障恢复、灰度与端到端验收。

查看独立示例的校验记录

巩固练习 按需完成 · 建议 15 分钟

为集团司库的“查询、分析、生成报告、审批发布”画边界和失败路径。

展开验收要求与检查点
  • 金额来自确定性计算
  • 读取与发布授权分开
  • 失败有可恢复或待核对状态

重点检查

  • 能够描述数据权限如何沿着 RAG、SQL 与报告产物传递。
  • 能区分任务状态持久化和外部副作用的一致性。
  • 能设计有限预算、失败恢复与人工审核的明确状态。