Agently Docs

English

中文

English

中文

Appearance

English mirror

This English page is generated from the current Chinese documentation so every route, anchor, code sample, and language switch stays available on agently.tech. Human-edited English copy can replace this generated body page by page.

Read the Chinese source page

文档审查全链路 Playbook ​

文档审查很容易被做成一个长 prompt：把合同、制度或规格说明丢给模型，让它直接写审查报告。这样 demo 很快，但系统很难上线。问题不在模型不会审，而是下游不知道它按什么路径审、证据来自哪里、高风险结论谁确认、报告质量怎么复核。

更稳的结构是把“审查”拆成几段可检查的能力：先路由，再拆任务，再做风险判断，再反思报告，最后服务化。

推荐演进路线 ​

版本新增能力解决的问题不要越过的边界
v0文档类型路由不同文档走不同审查框架路由只产出类型和配置 hint，不直接写完整报告
v1To-Do + 依赖图执行审查项由输入动态生成，可并发也可按依赖执行先抽取事实，再分析风险，不凭印象判断
v2风险审批高风险结论进入人工或策略闸门审批不是模型说“谨慎”，而是流程里的等待点
v3Reflection报告对照标准自检和修订评估调用独立于生成调用，避免自说自话
v4FastAPI 服务化产品和业务系统可以调用审查能力Router 只做接入、校验和返回，不承载审查核心

这条路线适合合同审查、制度审查、技术规格审查、合规检查、投研材料复核等场景。

模块边界 ​

模块输入输出Owner
classify_document原文、文件元信息doc_type、confidence、framework_id模型请求 + output schema
build_review_tasks原文、审查框架tasks[]、depends_on[]模型请求 + TaskDAG / TriggerFlow
run_task单个任务、依赖结果事实、风险、证据、建议AgentExecution / Actions
assess_risk所有任务结果risk_level、auto_proceed、reason结构化输出 + 确定性分支
reflect_report报告草稿、标准passed、missing_items、revision独立模型评估
review_apiHTTP 请求job id、stream、最终报告FastAPI / service layer

业务职责就是接口边界。每个模块只暴露下游需要的字段，不让别的模块读取自己的内部 state。组装层负责把上游输出打包成下游输入。

结构骨架 ​

text
review_document(input)
  |
  |-- classify_document
  |     -> doc_type + framework_id
  |
  |-- build_review_tasks
  |     -> tasks + depends_on
  |
  |-- execute_task_graph
  |     -> per-task facts / risks / evidence
  |
  |-- assess_risk
  |     -> low: continue
  |     -> high: pause for approval
  |
  |-- reflect_report
  |     -> revise until pass or budget exhausted
  |
  |-- return report + evidence refs

TriggerFlow 适合承载这条链路，因为它能让阶段、依赖图、审批等待、runtime stream 和最终 close snapshot 都有明确位置。

关键实现选择 ​

路由输出的是配置选择，不是最终判断 ​

路由阶段只回答“这是什么文档，应该使用哪套审查框架”。审查规则放在配置或 Skill / resource 里。这样新增文档类型时，优先改框架配置，不动下游审查模块。

To-Do 先抽事实，再做判断 ​

复杂文档审查最好让任务图里先出现事实抽取，再出现风险分析。让模型先看到原文事实，再基于事实判断，能减少凭印象写结论。

风险审批发生在执行后 ​

有些场景不是“执行前批准计划”，而是“所有分析都完成后，看风险等级决定是否出报告”。这类审批应该放在风险评估之后，不要和 Plan / Confirm 混成一个概念。

Reflection 是独立评估调用 ​

报告生成和报告评估应是两次独立调用。评估者只看草稿、标准和证据，不继承生成时的上下文。这样才能发现缺失项，而不是替原意图找理由。

服务层不要吞掉业务核心 ​

FastAPI router 只负责请求校验、调用 service、返回 job id / stream / result。审查流程、模型请求、配置读取和报告生成留在业务服务或 flow 层。这样 CLI、后台任务和 HTTP 入口能复用同一套核心能力。

什么时候引入 Workspace ​

只要出现这些情况，就不要把材料继续塞进 execution state：

  • 原文很长，后续只需要引用片段；
  • 中间审查结果要作为证据保留；
  • 最终报告、附件、截图或 PDF 要被下载和复核；
  • 后续轮次要基于上一轮结论继续；
  • 需要回放“当时为什么给出这个风险等级”。

推荐做法是把原文、任务结果、报告草稿和最终报告存成 Workspace record / artifact，flow state 只保留 ref、摘要和必要控制字段。

上线前检查 ​

检查项通过标准
路由每类文档都有稳定 doc_type 和审查框架映射
任务图每个任务有标题、目标、依赖和输出字段
证据风险结论能追到原文片段或任务结果
审批高风险路径有 pause/resume 或外部审批系统接入
报告质量Reflection 有明确标准、最大轮次和失败输出
服务化/health、提交接口、结果读取、stream 或 job 状态清楚
观测每个阶段有 trace / runtime stream / action logs

常见误用 ​

写法后果
一个 prompt 直接产出完整审查报告没有阶段证据，难以复核
用关键词路由文档类型复杂文档和混合文档容易错分
让下游模块读上游内部 state模块一改，整条链都碎
把人工确认写成 input() 堵住 HTTP worker服务化后无法并发和恢复
Reflection 不设最大轮次成本和等待时间不可控

另见 ​