开发者周报 Builder Weekly

AI时代的业务流程workflow该怎么做？bpmn还是agent

Sat, 12 Sep 2026 01:23:45 GMT

2026 年关于“业务流程该用 BPMN 还是 Agent”的讨论，很容易滑向两个极端：一种认为 Workflow 已经过时，另一种把 Agent 当成一个新的节点类型塞进旧流程。把厂商文档、开源实现、学术研究和金融机构的实践放在一起看，得到的答案不是二选一。

这篇文章要回答的问题只有一个：在金融服务里，确定性的业务流程和概率性的智能能力，应该怎么被拼在一起？

结论先放在这里：

金融服务不应该在 BPMN 和 Agent 之间二选一。BPMN/DMN 负责确定性的业务流程、业务规则和责任边界；Agent 负责流程内部那些难以规则化的认知任务；Workflow Runtime 负责业务状态和生命周期；Policy/IAM 负责 Agent 的权限；Agent 的输出必须以受约束的 Task Contract 返回，并经过确定性验证、以及按风险需要的人工批准，才能产生业务副作用。

这篇文章的结构

需要先说明一件事：本文前半部分讨论的 Agent-first 模型（Agent Runtime + Dynamic Plan + Durable Runtime），是通用 Agent 平台这一领域的真实主张，也是 2026 年厂商投入最大的一条线。它是趋势的一部分，但不是本文对金融业务的结论。所以全文按两条线组织：

部分	回答什么	性质
第一部分	为什么两个极端都不成立	问题定义
第二部分	行业四个架构领域各自在解决什么	趋势观察（含 Agent-first 领域）
第三部分	金融为什么不能照搬	约束条件
第四、五部分	主线架构与 Agent Task Contract	本文结论
第六至九部分	案例、选型、落地、长期演进	可执行部分

只想看结论的读者，可以直接跳到第四部分和第五部分。

第一部分：问题定义

1. 两个极端

Agent 进入业务流程的早期，工程团队通常会落到两个极端之一。第一个极端是“BPMN → Agent”：在既有的流程引擎里加一个 Agent 节点，把原来需要智能判断的那一步换成一次 LLM 调用；第二个极端是“Agent → Everything”：把整个业务流程交给 Agent：

flowchart TD
    B["Service Task"] --> L["LLM Node"]
    L --> S["Service Task"]
    A["User Intent"] --> AG["Agent"]
    AG --> T["Tools"]
    T --> O["Business Outcome"]

前者流程图画得很完整，看起来很可控；后者看起来很先进，演示效果通常也很好。

两个极端的问题不一样，但根子是同一个：它们都把“业务流程”和“认知任务”当成了同一种东西。注意 BPMN 和 LangGraph 都叫 Workflow 不是巧合——它们是两种不同的编排模型，第 5 节的四个问题是区分它们的标尺。业务流程要回答的是“做什么、谁做、什么时候做、结果去哪、出问题谁负责”；认知任务要回答的是“这一步具体怎么想清楚”。前者需要确定性，后者本身不确定。把它们混成一层，无论混在 BPMN 里还是混在 Agent 里，都会出问题。接下来三节分别说明：传统 Workflow 的边界在哪里，以及两种混法各自错在哪，错得有多贵。

2. Business Workflow 与 Agent Workflow 不是同一个东西

BPMN 和 LangGraph 都叫 Workflow，但它们解决的不是同一个问题。先把定义分开，后面所有选型都从这里推导。

Business Workflow 是由企业预先定义业务状态、责任、事件、审批和状态转移规则，并由 Runtime 持续执行的业务流程。例如：收到贷款申请 → 身份验证 → 信用检查 → 风险评分 → 人工审批 → 放款。核心不是“它是不是确定的”，而是：有 Business Process Definition，有 Process Instance，有业务状态，有角色与责任，有 SLA，有审批，有事件与定时器，有可治理的流程版本。

Agent Workflow 是以 Goal 为起点，由 Agent 或 Agent orchestration runtime 在运行过程中动态决定下一步执行内容的任务执行模型。例如：“调查这个投资机会，并给出一份结论” → search web → search Bloomberg → query internal database → read 17 documents → ask another agent → calculate valuation → discover missing information → search again → challenge its own conclusion → ask human → continue → produce report。重点不是“用了 LLM”，而是下一步执行什么在运行时才决定——这正是 LangGraph、Microsoft Agent Framework 这类系统与 BPMN 的核心差别。LangGraph 官方至今仍然区分 predetermined code paths 与 dynamic process / tool usage；Microsoft Agent Framework 则把 workflow 定义成 graph + executors + edges + events + state，并提供 sequential、concurrent、handoff、group chat、Magentic 等 agent orchestration 模式。([Microsoft Learn][48])([Microsoft Learn][49])

所以：传统 Workflow 的核心是 Business-defined Process Orchestration，Agent Workflow 的核心是 Runtime-driven Orchestration——区别不在 static vs dynamic，而在 orchestration authority 归谁。这是根本区别。

两种模型的对照：

	Business Workflow	Agentic Execution
起点	Business Process	Goal / Intent
谁定义路径	Business Architect	Agent
路径	Mostly deterministic	Dynamic
状态	Process Instance	Agent Task State
权限	IAM / Roles	Capability / Policy
责任	Human / Organization	Agent executes within authority
审计	Process Audit	Trace + Evidence + Audit
最终状态	Workflow Runtime	Workflow Runtime

一个容易被忽略的技术细节：BPMN 不是状态机

这里有一个在架构评审时经常被追问、但很多文档写错的点。严格来说，BPMN 是流程建模与编排的记法。运行时才产生 process instance，以及这个实例在流程图上的 token position 与执行状态。所以更准确的表述是：BPMN 提供确定性的流程模型和状态转移语义；具体某个 Process Instance 当前处于什么状态，由 Workflow Runtime 持有。把 BPMN 直接等同于“状态机”，作为通俗解释没问题，但写进架构文档会带来两个后果：一是把模型和运行时状态混为一谈；二是在讨论“状态到底应该存在哪里、出事故时以谁为准”时，失去判断依据。真正需要持有状态的是 Runtime，而不是图。这一点在后面的分层里很关键——因为“Agent 能不能改流程状态”这个问题的答案，取决于状态的所有权在谁手上，而不取决于图是怎么画的。

3. 第一个极端：给 BPMN 加一个 LLM Node

传统 Low-code 是拖一个 HTTP Node → 拖一个 Condition → 拖一个 LLM Node → 拖一个 Approval Node，看起来非常容易。但真正复杂之后，会冒出一串运行时问题：

LLM 为什么选择这个？
为什么重新搜索？
为什么调用这个 tool？
为什么跳过那个 task？
为什么 context 变了？
为什么 agent 重新规划？

最终暴露出来的问题是连节点只是表面工作，运行时行为才构成主要复杂度。于是最后会出现一个非常荒谬的东西：

Low-code workflow
Agent Node
Prompt
Memory Node
Agent Router
Tool Node
Agent Router
Condition
Agent Router

这实际上只是用 BPMN GUI 给 Agent 套了一层壳，不是长久方向。同样的道理，也不要把 Agent 的内部逻辑画进 BPMN。例如不要：

BPMN：

Agent Call
Agent Decision
Agent Decision
Agent Loop
Agent Retry
Agent Memory
Agent Tool
Agent Tool
Agent Subprocess

最终 BPMN 又变成另一种 spaghetti。正确方式是 BPMN 之下只放 Agent Activity，Agent Runtime 内部再拥有自己的执行模型。

4. 第二个极端：让 Agent 决定整个业务流程

这同样危险。最差的 AI Workflow，就是让模型自己决定整个业务流程，金融领域尤其不能这么做。例如：

Agent：

approve loan
move money
submit trade
change risk limit

这里不应该是 Agent 自由决定，而应该经过 Policy Gate 与 Verification 再回到 Agent。Agent 有 autonomy，但没有 unrestricted authority。这一点比 Workflow 这个词本身更值得先弄清楚。两个极端各自错在哪，到这里可以说得很具体了。它们错的不是“用了 BPMN”或“用了 Agent”，而是把基本单元搞错了。本文主张的基本单元不是“LLM Node”，而是 Agent Task：

flowchart TD
    BP["Business Process"] --> AT["Agent Task"]
    AT --> AR["Agent Runtime"]
    AR --> SR["Structured Result"]
    SR --> VG["Validation / Authorization"]
    VG --> BP

第一个极端把 Agent Task 降级成了一个 LLM Node，于是流程图画满了 Agent 的内部细节，却丢掉了智能本身；第二个极端把 Agent Task 升级成了整个业务流程，于是流程资产、责任边界与审批关系一起消失。第四、第五部分会把这条链路展开成完整架构与契约。

5. 选型四问：谁拥有 orchestration authority

BPMN 还是 Agent Workflow，真正要问的是四个问题。答案决定编排权归谁。

Q1：谁决定下一步？

Business Process Definition 决定的 → Business Workflow；Runtime Agent Decision 决定的 → Agent Workflow。这是最重要的一问。

Q2：谁拥有 Business State？

比如 KYC = APPROVED、RiskReview = WAITING、PMApproval = REJECTED，这是 Business State，应由 Business Workflow Runtime 拥有。而 search_done、peer_analysis_done、valuation_running 是 Agent Working State，可以由 LangGraph / Agent Framework 自己拥有。

Q3：谁是 Process Definition 的 Source of Truth？

问业务分析师“这个业务流程现在到底是什么”：如果答案是 BPMN Process Definition，BPMN 就是 authoritative workflow model；如果答案是 Agent code / graph / orchestration logic，Agent Workflow 就可以成为 authoritative orchestration model；如果答案是 BPMN 定义外层、Agent Graph 定义内部任务，那就是 Nested。

Q4：谁承担 Business Accountability？

为什么这个 loan 进入人工审批？为什么这个 case 被 reject？谁可以 override？SLA 到期之后走什么流程？这些问题如果要交给 Business Owner、Compliance、Operations、Auditor、Regulator 解释，那么这部分不能只存在 Agent working plan 里。

6. 什么时候应该只使用 Business Workflow

满足以下大部分条件，优先使用 BPMN / Workflow Engine：Business State 明确，State Transition 明确，Roles 明确，Approval 明确，SLA 明确，需要跨系统协调，需要长期运行，流程版本受治理，审计需要看到流程路径。例如 Account Opening、KYC、Trade Settlement、Payment、Loan Approval、Regulatory Reporting、Claims Processing——这些流程不应该为了 Agent 热潮改成 LangGraph。

7. 什么时候可以直接使用 Agent Workflow

反过来，满足以下条件时，纯 Agent Workflow 完全合理：Goal 明确但执行路径未知，需要探索、工具选择、动态规划、多 Agent 协作，没有正式业务状态机，没有监管流程定义要求。典型如 Investment Research、Market Intelligence、Internal Knowledge Investigation、Research Memo Generation、Complex Document Analysis、Incident Investigation。

比如“判断某家公司是否值得进入我们的投资候选池，并准备研究报告”——如果强行 BPMN 化（Search Company → Retrieve Filing → Peer Analysis → DCF → Missing Info? → Search Again → Ask Specialist → Critic → Recalculate），会非常难维护。这种情况下 LangGraph、Microsoft Agent Framework、DeepAgents 或自研 Agent Runtime 完全可以成为主要 orchestration 层。

8. 金融最常见的最终形态：Nested Orchestration

当前面两节同时成立——外层有正式业务流程、内层任务需要动态探索——答案就是 Nested：Business Workflow 定义外层，Agent Workflow 定义内部任务，BPMN 是 Business Process Source of Truth，Agent Graph 是 Agent Task Source of Truth。例如 Investment Idea Review 之下，Research、Risk Review、Compliance Review 各自内部跑一条 Agentic Workflow（搜索、估值、证据核查、重新规划），最后回到 BPMN 做 PM Approval。

Agent Task 从哪里读业务事实，是 Nested 落地时的第一个实际问题：答案是第 9 节的 Business Data Contract（authoritative source、snapshot、context version、consistency window）。完整的五层分层见第 25 节。

9. Business Data Contract：Agent 看到的是哪一个版本的业务事实

金融 Agent 落地时，最大的问题往往不是 Agent Runtime 的能力，而是 Agent 到底看到的是哪一个版本的业务事实。考虑一个很普通的时间线：

10:01 BPMN: Risk = 0.82
10:05 Agent: 查 Snowflake，得到 Risk = 0.77
10:10 Human: 界面上看到的是 0.79

三个数字都“正确”，因为它们来自三个时间点的不同来源，但在审计场景里，这直接导致结论无法复现。

所以架构上不能只有：Agent → Snowflake。而要有 BPMN Process Instance → Business Context → Approved Data Snapshot（Authoritative Source）→ Agent Task → Structured Result → 回到 Process Instance 的闭环。

具体要确定的是四件事：

权威源（authoritative source） —— 某个业务事实以哪个系统为准。Portfolio value 是来自交易系统、估值系统还是数仓，必须指定唯一答案。允许两个系统都“能查到”，就等于允许两个结论。

快照语义（snapshot semantics） —— Agent Task 开始时的业务上下文是否被冻结。如果冻结，整个 Task 内的所有查询都基于同一版本；如果不冻结，就必须显式记录每一次读取的时间戳，并接受结论建立在“混合版本”之上。

版本标识（context version） —— 这个 context 需要一个可写入 Evidence 的标识，让事后能回答“当时它看到的是哪一版”。这是第 22 节里 Level B 可复现的前置条件。

跨系统一致性窗口 —— Position、Market price、Risk score、Compliance status 来自不同系统，同步延迟不同。要么给出一个显式的一致性窗口，要么承认“不保证一致”并把风险写进设计文档。最怕的是既没有窗口、也没有声明，等到争议出现时才发现无法解释。

这一层决定了 Agent 的输出能否被复核。模型可以换，harness 可以换，Agent Runtime 的框架可以换，但只要 Data Contract 是清楚的，历史决策至少可以在“同样的业务事实 + 记录在案的规则版本 + 记录在案的 Agent 轨迹”这三个条件下被复核。反过来，如果 Data Contract 不清楚，任何 audit trail 都建立不牢——因为审计看到的是一堆记录，而不是一条能走通的证据链。

一个可复现的版本栈

把上面的四件事合起来，一个金融 Agent 的 Task 要在事后被完整解释，需要同时记住六个版本标识：

workflowVersion = investment-idea-review v17
policyVersion = compliance-policy v8
dataSnapshot = ctx-20260912-1030
modelVersion = model@version
promptVersion = compliance-review v12
evidenceRef = doc-123#p17

有了这六项，才能回答“为什么当时这个 Agent 会得到这个结论”。缺任何一项，复盘都会退化：只记 workflow 版本，说明不了 Agent 为什么这样判断；只记 model 版本，说明不了它当时看到的是哪一版业务事实。反过来也要说清边界：版本标识解决的是“可复现”，不是“可信任”。记录齐全只保证结论可以被重新推导，不保证结论正确。正确性由业务规则、验证与必要的人工审批负责。这两件事经常被混为一谈，结果是团队花大力气把日志做完整，却依然回答不了监管最关心的那个问题。这也是 Data / Semantic 层不应该被塞进 Control Plane 的原因：它回答的是“世界是什么样”，Control Plane 回答的是“谁被允许做什么”。

第二部分：业界趋势

下面不按厂商罗列，而是按第 5～8 节的决策框架，看三种模式在 2026 年产品里的真实样子：Camunda、Fluxnova 是 Business Workflow；LangGraph、Microsoft Agent Framework 是 Agentic Orchestration；Temporal、Durable Task 是正交的 Durable Execution。厂商名只是实现，决策维度才是选型的依据。

10. 四个架构领域总览

2026 年的行业实践，可以按“各自解决什么问题”归成四个架构领域。它们不是互相替代的关系，而是分别占住了架构的不同层。

领域	解决的问题	主要线索
领域一 · 确定性业务编排	流程、责任、审批、SLA、审计	Camunda / Fluxnova
领域二 · Agent Runtime 与 Harness	Agent 如何工作	OpenAI / Anthropic / LangGraph / Microsoft / Google
领域三 · Durable Execution	Agent 如何可靠地长期运行	Temporal / Durable Task
领域四 · Enterprise Semantic & Data	Agent 在什么世界里工作	Palantir / Snowflake

四个领域共同指向同一个组合点：Agent Task Contract。

这个分组方式本身就是一个判断：这四件事不在同一个维度上，不能用“谁替代谁”来讨论。其中有一处需要额外说明：领域三（Durable Execution）严格来说不与另外三者处在同一层，而是一层基础能力。它不解决“Agent 怎么决策”，也不解决“流程怎么定义”，它解决的是“执行到一半进程崩了怎么办”。把它当成一个可选方向去和 BPMN 比较，是选型时最常见的误判之一；把它当成所有长任务路径都必须具备的底座，才是它的真实位置。把领域二三混成一句“Agent Workflow 取代了 BPMN”，是这一轮技术讨论里最普遍的一次偷换。后面的第 46 节会把这个问题拆到产品层面。

11. 领域一 · 确定性业务编排（Camunda / Fluxnova）

为什么用 BPMN 引擎承载 Agent Workflow 会让人本能地抵触？Fluxnova 仍然是 BPMN 引擎：

BPMN
DMN
Human Task
Process State
Audit

它现在已经开始加入：

ad-hoc subprocess
agentic subprocess
MCP
AI integration
dynamic routing

但它仍然是 BPMN-centered orchestration，没有转到 Agent-centered execution runtime。Fluxnova 3.0 本身仍以 BPMN Process Engine 为核心，只是增加了 Ad Hoc Subprocess 等动态能力；其 roadmap 甚至把 AI integration 放到了后续能力路线。(GitHub)

更准确的说法：deterministic + dynamic，而不是“把 Agent 塞进 BPMN”

前面那句“Camunda 的方向是把 Agent 塞进 BPMN”，只说对了一半。Camunda 8.7 的官方文档已经把这件事定义得非常明确：agentic orchestration 是把确定性编排和动态（AI 驱动）编排混合进同一个端到端流程。原文的表述是，AI agent 负责执行流程中非确定性的部分，而 BPMN 提供可预测性、合规性和客户体验的底座。(Camunda 8 Docs)

分工是清楚的：

LLM → 决定调用什么工具、以什么顺序、什么时候停止
Camunda → 执行 BPMN elements
Camunda → 保存 process state
Camunda → retry / incident
Camunda → human task
Camunda → 确定性逻辑
Camunda → process boundary

所以更准确的表述是：Camunda 选择的是在 Business Workflow 内原生支持 Agentic Orchestration——AI agents 执行 non-deterministic parts，BPMN 保持 end-to-end process 的可预测性和合规性。这不再是“Camunda 更先进”，而是 Camunda 选择了 Nested / Integrated 模式，并且把两种 orchestration 都收进一个平台。具体的设计与架构建议，见 Camunda 的《Design and architecture》文档。(Camunda 8 Docs)本文要讨论的是这个边界应该由什么契约来定义。这对金融、保险、银行很合理。但如果目标是一个 AI-native Agent Platform，BPMN 不适合作为核心抽象。

补一条 2026 年中的新进展：Camunda 8.10 把 Agent 建模成了一等执行对象，明确区分 Agent Definition 与 Agent Instance——定义描述部署的 Agent，实例代表某一次具体运行；BPMN 元素实例与 Agent 实例也不是同一个生命周期对象，同一个 Agent 实例可以在同一次流程实例里被多个元素实例复用（比如人工回复后流程回到 Agent 节点，对话记忆不断）。Operate 里可以直接看到 Agent 的执行状态、用量与完整推理链，LangGraph 这类外部框架经由 Agent Instance API 上报后同样可见。(Camunda 8 Docs)这正是“Agent 正在成为 Workflow Runtime 中的一等执行对象，但仍然不是 Business Process 本身”。

12. 领域二（上）· 执行模型

这个领域的主张最激进，投入也最大。它并不否认 Workflow 的存在，而是主张 Workflow 的实现方式应该被重写。在评价它之前，先把它自己的主张摆出来。而比较合理的模型其实是：User / Business Event → Intent → Agent Runtime（含 Policy / Authority、Context / Memory、Tools / APIs / MCP、Dynamic Plan）→ Execution Runtime（Deterministic Code / Agent Task / Human Task / External Event 分支汇总成 Result，再经 Verification / Policy Check 回流 Agent），另有一条 Durable State + Event Log 做底座。

这里先说两件事：在 Agent-first 架构中，Agent 可以动态决定下一步的任务或工具调用；但在金融业务流程中，这种自由度被限制在 BPMN 定义的 Agent Task 边界内。Runtime 决定“这个下一步能不能做、怎么执行、出了问题怎么办”。第一点是这个领域与过去 Workflow 最大的区别，也是它后来必须被限制的地方；第二点则不受领域之争影响——无论目标是什么，执行边界都必须存在。

Google ADK 2.0

Google 在 2026 年把 ADK 从原来的 hierarchical agent executor 明确转向 Workflow Runtime + Graph-based execution：Agent、Tool、Function 全部作为 workflow graph 的节点，并支持 branching、parallelism、loops、human-in-the-loop、state preservation 与 resume；原来的 SequentialAgent / LoopAgent 正逐步被 graph workflow 取代。(GitHub)先看它的立场，而不是它说了什么：不是“Agent 出现了，所以 Workflow 消失”，而是“Workflow 的实现方式必须适应 Agent”。

Microsoft Agent Framework

Microsoft Agent Framework 现在把 Workflow 定义成：

Executors
Edges
State
Events
Runtime

而 Executor 可以是：

普通代码
Agent
Tool
sub-workflow

并且 runtime 负责：

execution
events
checkpointing
HITL
concurrency
state management

也就是说，Workflow 不再等价于 Business Process Diagram，而是一个可执行的 runtime topology。(Microsoft Learn)

LangGraph

LangGraph 把自己定位成 low-level orchestration framework for stateful agents。它的核心价值不是“画流程”，而是：State → Node → Decision → Tool → Checkpoint → Resume。它特别强调 durable execution、stateful agents、long-running execution 与 failure recovery。也就是说，Graph 在这里不是给业务人员看的流程图，而是 Agent 的执行 runtime。(GitHub)换句话说：LangGraph 是 Agentic Orchestration Runtime，不是 Business Process Management 的直接替代品。但要加一句限定——如果企业的业务流程本身就是 Agentic Task，它当然可以成为整个业务流的 orchestration runtime。问题从来不是“LangGraph 能不能做业务流程”，而是“不要默认它就是 Business Process Engine”。所以不要再想 Workflow = DAG / BPMN，而应该定义：所以不要再想 Workflow = DAG / BPMN，而应该定义：

Agentic Execution：

Intent
Policy
Execution State
Dynamic Plan
Durable Runtime

这里用 Execution 而不用 Workflow 是有意的：Intent 是输入，Policy 是控制，Dynamic Plan 是决策，Execution State 是状态，Durable Runtime 是基础设施——五件事不在同一层，“Agentic Workflow”这个名字会把它们压成一个词。

① Intent

起点不是 Start → A → B → C，而是一个目标，例如“完成投资机会尽调并生成投资建议”。Agent 负责寻找完成这个 Goal 的路径。

② Policy

这个才是企业 Workflow 最应该固定下来的东西。例如：

policy:
  can_read: [market_data, research_db]
  can_write: [draft_report]
  approval_required: [execute_trade, send_external_email]
  forbidden: [customer_pii_export]
  max_budget: { tokens: 100000, tool_calls: 50 }

也就是说，流程可以变动，要固定下来的是权限和边界，这比 BPMN Gateway 更实在。

③ Dynamic Plan

Agent 根据目标动态产生工作计划：搜索公司、取财务数据、分析竞争对手、发现信息缺口、再搜索、建模估值、复核假设、产出报告——顺序与内容都由 Agent 自己决定，而不是预先画在流程图上。这个 Plan 对长跑 Agent 而言确实需要持久化，而不是只存在 LLM context 里。但要区分清楚：持久化的是 Agent Task 的执行状态，不是企业业务流程的状态——这一点在第 54 节展开。例如：

{
  "runId": "invest-20260912-001",
  "goal": "Evaluate XYZ",
  "plan": [
    {
      "id": "t1",
      "type": "research",
      "status": "completed"
    },
    {
      "id": "t2",
      "type": "valuation",
      "status": "running"
    }
  ]
}

在这个领域的语境里，“Workflow”的含义已经发生位移：在 Agent-first 系统中，Agent Task 的内部执行计划可以由 Agent 动态生成；它不等于企业 Business Workflow Definition。这是 Agent Platform 视角下的结论。一旦把目标切到企业业务流程，这个区分就变成架构上的硬边界——第 24 节会把两种“计划”明确分开。

④ Execution State

这是传统 Workflow Engine 最值得保留的东西。真实的长任务经常是“跑 25 分钟 → 等待人工 → 6 小时后继续”，状态至少要能区分：

RUNNING / WAITING_TOOL / WAITING_HUMAN / WAITING_EVENT
FAILED / RETRYING / COMPLETED / CANCELLED

需要的是 durability、checkpoint、resume、timeout、retry、compensation 与 idempotency，而不是漂亮的流程图。这一点比 BPMN 图本身更实在。

⑤ Execution Runtime

真正的核心应该是 Agent Brain 与 Agent Execution Runtime 的分工：Agent 只负责提议，Runtime 负责授权、验证、执行与审计，中间经过 Policy Engine、Authority、Sandbox、Durable State 与 Event Log 这些统一边界。

Agent 不应该绕过统一的身份、权限、工具和审计边界，直接拿到未治理的生产系统权限。这句话不等于“Agent 不能访问生产系统”。它可以访问，但访问必须走完整链路：Agent → Task Context（业务上下文 + 流程实例 + 数据版本） → Tool / Capability → Identity / Authorization → Target System。而不是：Agent → 万能 production credential。这里有一个金融场景特有的细节：Authorization 判断的不只是 Agent 的身份。同一个 Agent，对 Investment A 与 Investment B 的权限可能相同，但业务上下文、交易上下文、数据版本与流程实例不同，允许的动作就可能不同。所以完整的授权输入应该是：

Agent
User
Workflow Instance
Business Object
Action
Context

只写“Agent Identity / Authority”，在评审时会被简化成“这个 Agent 有没有权限”，而金融机构真正要回答的是“在这个 case、这个版本的业务事实上，这一步动作是否被允许”。Agent 只负责 propose、reason、choose 与 delegate；Runtime 负责 authorize、validate、execute、retry、pause、resume 与 audit。这其实就是未来 Agent Platform 最核心的一层。内部 AI Platform 也可以按同一个方向设计：把 Planning、Context 与 Tool Gateway 收进 Agent Runtime，把 Durable State、Event Log 与 Human Task 放在执行侧，再把 Evaluation / Trace 接在末端。这与第 50 节那张平台分层图是同一个判断的两种画法，这里不再重复贴图。需要补一句：BPMN / Camunda / Fluxnova 是一个“外部能力”，不是整个 Agent Platform 的核心。这和今天很多企业的架构思路会完全不同。需要补充一句：这不是本文对金融场景的结论。在金融场景里，BPMN 恰恰是核心控制面，而不是外围能力。两句话并不矛盾，差别只在目标是通用 Agent 平台还是企业业务流程。

Microsoft 的第二条线：Durable Runtime

微软实际上同时押了两个方向——Agent + Workflow + Durable Runtime，而不是二选一。除了上一小节那个 graph workflow 模型之外，它还提供了 checkpoint、human-in-the-loop、fan-out / fan-in、sub-workflow、typed routing、graph execution 与 durable execution。更重要的是，微软直接提供 Durable Extension，把 Agent Framework 的 graph workflow 跑在 Durable Task 基础设施上：Agent Framework → Graph Workflow → Durable Task → Checkpoint → Resume → Distributed Workers。并支持 agent 运行数天甚至数周。(Microsoft Learn)这里已经非常接近这样的三段式模型：Agent 是 intelligence，Workflow 是 execution topology，Durable Task 是 runtime。这是一个很好的概念分层，但要补一句：概念分层不意味着产品分离——“同一套 workflow 定义，换个 host 就获得 durability”，一个产品同时承担其中两层甚至三层是常态。(Microsoft for Developers)Microsoft 的框架恰好是证明“Agent Workflow 和 Business Workflow 可以共享同一种 runtime abstraction，但不拥有相同业务语义”的边界案例：Workflow 由 executors + edges 组成 directed graph 并管理执行（[Microsoft Learn][48]），之上是 sequential、concurrent、handoff、group chat、Magentic 等 agent orchestration 模式（[Microsoft Learn][49]），Workflow 可以 as_agent 暴露、Agent 也可以作为 executor 进入 Workflow（[Microsoft Learn][50])——但语义归属不变，Business 语义仍由持有业务状态与责任的一方定义。

13. 领域二（下）· Harness 被产品化

上一节讲的是“Agent 的执行模型长什么样”，这一节讲的是“厂商正在把什么产品化”。这里有一个值得单独拿出来看的趋势：Agent Harness 本身正在成为独立的基础设施，而不是某个框架的内部实现细节。一旦它可以被单独产品化、单独版本化、单独定价，它在架构上的地位就变了——它从框架的内部细节，变成一层需要被认领的架构。

Anthropic：Claude Research 的多 Agent 结构

Anthropic 的做法和微软略有不同。它最经典的生产案例是 Claude Research：一个主 Agent 制定研究计划，再启动多个并行 Agent 搜索，最后汇合。

Anthropic 明确指出，系统设计最大的难点已经变成 coordination、evaluation、reliability 与 tool design，而不是传统 workflow 的节点设计。(Anthropic) 这与传统 BPMN 的思路差别很大。

Anthropic 的第二条线：Harness

Anthropic 对 Agent 的工程实践越来越集中到 Harness，而不是 Workflow Designer。它 2026 年的工程文章把 long-running agents、managed agents、context engineering、skills、tool use、security、agent containment、evals 与 multi-agent research 分成几条独立的线推进。(Anthropic)也就是说，Model + Harness + Tools + Environment + Permissions + Context + Evaluation 正在成为一个比传统 workflow 更核心的抽象。不过要说清楚：Anthropic 的公开实践集中在 Harness、Tool Use、Context Engineering、Containment 与 Evaluation，并没有提出一套企业业务流程架构。把它的工程文章读成“BPMN 的替代方案”，是过度解读。

OpenAI：从 Agents SDK 到 harness + sandbox

OpenAI 2025 年最初的方案是 Responses API + Agents SDK + Tools + Handoffs + Guardrails + Tracing，已经明显不是传统 workflow。2026 年更进一步，新的 Agents SDK 强调 model-native harness + sandbox + long-horizon task：Agent → Harness → Sandbox → Tools / Files / Commands → Long-running execution。并且把 harness 与 compute 分离，强调 security、durability 与 scale。(OpenAI)（OpenAI）这里还有一层意思：Agent Workflow 最终可能不是 DAG，而是一个“可持续运行的 Agent Process”。

2026-09-10：OpenAI 把 Harness 单独产品化

这条更新对本文的论证尤其重要，因为它是一个非常直接的证据。OpenAI 在 2026-09-10 发布 Agents API，把驱动 Codex 的同一套 harness 与基础设施开放出来，并且明确由 OpenAI 托管和维护。(OpenAI)它提供的能力清单很能说明问题：

managed harness
long-running sessions（模型可以连续工作数小时）
context management（接近上下文上限时自动压缩早期上下文）
sandbox（OpenAI 托管沙箱，或自带基础设施 / 第三方沙箱）
subagents（把任务拆给并行子智能体）

而开发者只需要定义四样东西：task、model、tools、environment。其余运行时基础设施——会话、上下文压缩、沙箱、并发子智能体调度——由平台负责。(OpenAI)这里有两层含义，方向相反，必须一起看。第一，它支持“Agent Runtime / Harness 正在成为独立基础设施”这个判断。当一个 harness 可以被单独产品化、单独版本化时，它就不再是框架的内部细节，而是一层需要被认领的架构。第二，它同时反证了 Agent Runtime 不等于 Business Workflow Runtime。Agents API 提供的“orchestration”指的是单个 Agent 会话内部的任务编排：决定先查什么、再调什么工具、什么时候停止。它不持有企业流程状态，不负责跨部门审批，也不会为一个投资 Idea 的合规责任签字。这两件事都被称为“编排”，但归属完全不同。这是后面反复要用的一个区分。

内部应用：delegated long-horizon task

OpenAI 在公开材料里把内部 Codex 的工作单位定义成 delegated long-horizon task，而不是 single interaction：员工把一件长周期任务整体交出去，Agent 自己使用工具、文件与代码反复迭代，直到交出结果。(OpenAI)

OpenAI Presence：企业 Agent Operating Model

2026 年推出的 Presence 尤其值得注意，它的切入点不是 Workflow Designer，而是一个具体岗位：specific job → knowledge → system access → permissions → policies → agent → escalation → human。每个 Agent 都有明确的权限、工作范围、approval 与 escalation，典型场景是 billing、insurance claims 与 IT service request。(OpenAI)这已经非常接近金融机构需要的模型。

Google：Agent Platform + Enterprise Governance

Google 2026 年提出的 Agentic Enterprise blueprint 是 Agent + Agent Platform + Orchestration + Governance + Enterprise Data，而不是 BPMN + LLM Node。Gemini Enterprise 被明确定义成 agent development + orchestration + governance 的一体化平台，并开始支持 long-running agents、agent collaboration spaces、advanced governance 与 agent marketplace。(Google Cloud)（Google Cloud）2026 年 5 月 Google 又推出了 Agent Executor，一个分布式 Agent Runtime：durable execution、失败与 HITL 中断后可恢复、沙箱隔离、分布式部署，而且 harness-agnostic——自带 harness 与 LangGraph 这类第三方框架都能跑在上面。(Google Cloud)这正是“Agent Runtime + Durable Execution 合在一起交付”的又一个实例。这说明大型企业平台厂商的竞争重点，正在从“谁有最好的 Agent Builder”转向谁能提供企业级 Agent Operating Environment。

Snowflake：Data-native 的 Agent 平台

Snowflake 的 Cortex Agents 架构已经非常清楚：

具体是 Cortex Agent 之下分 Cortex Analyst / Cortex Search / Code 三路，分别接结构化数据、非结构化数据与算力，再汇入 Reasoning 做 Action。

官方明确说 Cortex Agents 自己负责 reasoning、plan work、call tools、execute code、maintain threads 与 multi-step orchestration，客户不需要自建 orchestration loop / runtime / sandbox。(Snowflake Documentation) 2026-08-28，Snowflake 进一步建议从 Cortex Analyst 迁移到 Cortex Agents，原因就是后者把 structured data、unstructured data、tool calling、thread context 与 multi-step orchestration 放进了同一个 Agent runtime。(Snowflake Documentation)针对 Financial Services，它的主张不是“做一个金融 Agent”，而是把 first-party data + third-party data + semantic layer + search + agent + action 组合起来，通过 Cortex Analyst、Cortex Search、Shared Semantic Views、Knowledge Extensions 与 Cortex Agents，让 Agent 在数据所在的位置执行 workflow。(Snowflake)这对银行、资产管理、保险特别重要。

一个必须写清楚的区分

Snowflake 的 Cortex Agents 确实提供 reasoning、planning、tool calling 与 multi-step orchestration。(Snowflake Documentation)但这里必须写清楚一句话，否则很容易被误读：Cortex Agents 的“workflow / orchestration”是 Agent 内部的任务编排，不等同于金融企业的 BPMN Business Process orchestration。它不替代 Camunda 这类流程引擎，也不承担流程状态、跨部门审批与责任归属。两者是上下游关系：流程引擎决定“这一步该做合规审查”，Cortex Agents 负责“在这次合规审查里把数据查清楚”。

14. 领域三 · Durable Execution（Temporal / Durable Task）

Temporal 的思路甚至更激进：Workflow 之下挂四个 Activity——Activity → LLM、Activity → Tool、Activity → Database、Activity → API。

Workflow 本身负责：

state
ordering
waiting
retry
timeout
resume

所有 nondeterministic I/O 都放在 Activity。Temporal 最近专门发布了 AI Agent Reference Architecture，把 Agent 的 loop 放进 durable Workflow 中。(Temporal)所以它实际上把两份责任分开了：Workflow 只做确定性编排，所有非确定性 I/O（LLM、Tool、API、DB）全部封装进 Activity。注意这里的“分开”指的是责任——Temporal 自己的做法恰恰是让 Agent Loop 运行在 durable Workflow 之内。不要比较 Camunda vs LangGraph vs Temporal，这个比较本身就不对：

flowchart TD
    A["Orchestration Model"] --> B["Business Workflow"]
    A --> C["Agent Workflow"]
    B --> D["Durable Execution"]
    C --> D

Temporal 是 Execution Model / Durable Runtime，而不是另一种 Business Process Definition。上面的案例正好说明：Agent Workflow 可以拥有 Durable Execution，而不等于它因此变成 Business BPM。

为什么这一层必须单独存在

Microsoft 的 Durable Extension 也属于这一层：Agent Framework 的 graph workflow 跑在 Durable Task 基础设施上，支持 checkpoint、resume，以及数天到数周的运行周期。(Microsoft Learn)把 Durable Execution 与 Agent Workflow 分开的理由，是它们的失败模式不同：

Agent Workflow 失败：Agent 选了错误的工具，或推理方向错了
Durable Execution 失败：进程崩了、网络断了，执行无法恢复到崩溃前的状态

前者是决策质量问题，后者是执行可靠性问题。但这是责任要分开的理由，不是产品要分开的理由：同一个 Runtime 完全可以同时承担两种责任。Microsoft 的实践就是直接证据——同一套 workflow 定义，跑 in-process runner 是本地执行，换 Durable Task host 就获得 checkpoint、恢复与分布式执行，executor 代码一行不用改，每个 executor 在 dashboard 里就是一个 durable activity。(Microsoft for Developers)

15. 领域四 · Enterprise Semantic & Data Layer

前三个领域都在回答“Agent 怎么工作”，这一个回答的是另一个问题：Agent 面对的世界，是用什么语言描述的？

Agent 到底应该连接什么

因为 Palantir 其实回答了一个很关键的问题：Agent 到底应该连接什么？Palantir 的答案不是让 Agent 直连上千个 API / Table / PDF，而是先经过一层 Enterprise Ontology——官方把它概括成 Data + Logic + Action + Security。(Palantir)

flowchart LR
    subgraph OLD["传统方式"]
        Q1["Agent"] --> API["大量 API / Tables / Documents"]
    end
    subgraph NEW["Ontology"]
        Q2["Agent"] --> ON["Enterprise Ontology"]
        ON --> OBJ["Objects"]
        ON --> ACT["Actions"]
        ON --> RULE["Logic"]
        ON --> SEC["Permissions"]
    end

更形象一点：Ontology 之下是 Company → Investor / Security → Transaction → Actions 这样的业务对象网，而不是 table 和 database。所以 Agent 看到的不是 table / API / PDF / database，而是 Company / Portfolio / Position / Transaction / Risk / Counterparty / ResearchReport，并且这些对象自带 actions、logic、permissions 与 relationships。

Action 模型：nouns 与 verbs

Palantir 有一个很值得重视的思想：数据只是“nouns”，Action 才是“verbs”。也就是说，Company、Position、Loan、Customer、Transaction 这些是 nouns，而 Approve、Reject、Rebalance、Create、Assign、Escalate、Freeze、Review 这些才是 verbs。(Palantir)这恰好解决 Agent 最大的问题：Agent 不只需要知道“这个东西是什么”，还需要知道“对它允许做什么”。

Ontology 与 RAG 的差别：world model + action model

传统 RAG 是 question 到 top-k documents 再到 LLM；Ontology 则把 Data、Logic、Action 先收进 Security，再交给 Agent 做 Real Action——从架构角度看，它更接近 Agent 的 enterprise world model + action model，而不是一个 Vector DB。（这是本文的架构解读，不是 Palantir 的官方定义。）Ontology 在整个 Agent 架构里的位置是：

flowchart LR
    AR["Agent Runtime"] --> ON["Enterprise Ontology"]
    ON --> DT["Business Data"]
    ON --> AC["Business Actions"]
    AC --> PO["Authorization"]
    PO --> EX["Controlled Execution"]

Ontology MCP：把语义层变成 Agent 的 substrate

这一步尤其重要。2026-06 Palantir 已经正式 GA Ontology MCP。意味着：

Claude
OpenAI
Gemini
Microsoft Agent Framework
Google ADK

这些产品本身都支持 MCP，因此任何兼容 MCP 的 Agent / Agent Framework 都可以通过 MCP 做 read Ontology、write Ontology 和 execute Ontology actions，而且调用继续使用 Foundry 权限模型。(Palantir)换句话说，Ontology 不需要成为 Agent Framework，它变成 Agent 的 enterprise semantic/action substrate，这比“Palantir 自己做 Agent Framework”更重要。

AIP Logic：No-code 没有死，但不再是抽象核心

AIP Logic 仍然是 no-code。它可以做 Ontology Object 到 LLM 再到 Condition、Loop、Function 和 Action 的串联，并且支持 testing、evaluation、monitoring、automation 和 human review。(Palantir)所以 Palantir 的实际答案不是“No-code 已死”，而是 No-code 不能再是整个系统的抽象，它只是 Ontology / Logic / Action 上面的一个 builder，这个区别直接决定后面怎么搭。

Snowflake 的另一条变化：RAG 走向“分析型检索”

2026 年 Snowflake 推出了 Analytical Search。传统 RAG 是 question 到 top-k documents 再到 LLM，对于“10000 份财报中，有多少家公司……”这类问题其实不行。Snowflake 的新方向是 Agent 调度 multiple Search queries、metadata filters、AISQL、AI_FILTER、AI_AGG，最后 aggregate entire corpus：Agent → multiple Search queries → metadata filters → AISQL → AI_FILTER → AI_AGG → aggregate entire corpus。也就是说，Agent 不只是“找资料”，而是能够调度一套数据处理 workflow。(Snowflake Documentation)这个对金融 research、compliance、credit、ESG 很实用。

16. 学术界：Agent Workflow 已经成为一等研究对象

厂商文档之外，还有一个更值得看的信号：研究界已经不再把 Agent 看成“一个 LLM 加几个工具”，而是把 Agent Workflow 本身当成研究对象。这条线上有几篇值得当作入口的论文。

1. 《A Survey on Agent Workflow — Status and Future》

这是目前比较值得当作入口的 survey。论文把 Agent Workflow 按两个维度分类：功能上分 planning、多 Agent、API、tool、memory，架构上分 agent role、orchestration flow、workflow specification。它明确指出，随着 Agent 系统变复杂，workflow/orchestration 已经成为 scalable / controllable / secure agent behavior 的核心基础设施，同时指出标准化、安全和多模态 integration 仍是开放问题。(arXiv)这意味着一个很重要的判断：Workflow 不会消失，只是在从“业务流程建模”变成“智能执行系统建模”，这点很容易被企业架构师忽视。

2. 《Architectural Implications of Agentic AI Workflows》

2026 年 8 月的研究直接分析 Agentic Workflow 对底层基础设施的影响，核心发现是 Agent 的执行路径：Agent Request → LLM 推理 → Tool 调用 → CPU 执行 → LLM 推理 → Tool 调用 → 不断重复。

Agent 不是传统 ML 那种 input → GPU → output，而是 CPU、GPU、network、external systems、orchestration 不断交替：

CPU
GPU
network
external systems
orchestration
CPU
GPU
…

不断交替。结果就是 CPU/GPU 利用率不均衡，execution bursty，tool invocation 造成 CPU critical path，multi-agent 增加调度复杂度，heterogeneous workloads 使传统 server provisioning 变得低效。论文甚至做了专门的 Agentic Server 原型 Agora。(arXiv)这其实说明 Agent Runtime 最终可能会成为一种全新的计算运行时，而不只是 Python framework。

Workflow 定义本身也在 AI 化

以前是 Developer 设计 Workflow 再部署：Developer → 设计 Workflow → 部署。以后可能是 Business Intent 经由 Agent / Compiler，结合 Execution Policy 生成 Generated Plan 再交由 Runtime 执行：Business Intent → Agent / Compiler → Execution Policy → Generated Plan → Runtime。也就是说，Workflow 从“静态 artifact”变成“动态 execution artifact”。最近研究也开始直接研究 Agentic Workflow Generation，也就是从功能描述自动生成可执行 workflow，而研究结果同时指出：单纯让 LLM 生成流程很容易产生缺失/幻觉数据，因此真正可靠的方向是生成 + 约束 + runtime validation，而不是“让 LLM 随便画流程”。(Springer Nature Link)

甚至“Workflow”这个词都可能被弱化

未来更准确的词可能是 Agent Runtime、Agent Execution 或 Task Orchestration，而不是 Workflow Engine。在这个基础上，把 Agent 平台抽象成“Agent Operating System”是一个值得关注的研究方向——需要说明的是，它目前仍然只是研究提案，不是已经被行业标准化的架构。一个 2026 年的代表性工作提出 Agent Operating System (AOS)，把系统分成 Control & Governance Plane 与 Runtime & Coordination Plane：前者负责 intent、policy、authority、trust、audit 与 human oversight，后者负责 agent lifecycle、workflow coordination、model/tool routing、memory、scheduling 与 runtime assurance。(arXiv)值得关注的原因不是这个词，而是它把“控制面”与“运行面”分开的方式，与本文后面的分层判断一致。

17. 阶段结论：四个领域怎么组合

到这里可以看到一个比较清楚的分工：

主体	解决的问题
Palantir Ontology	解决：世界是什么、能对世界做什么
Anthropic / OpenAI	解决：Agent 如何工作（Harness）
Microsoft / Temporal	解决：Agent 如何可靠地长期运行
Snowflake / Google	解决：Agent 如何在企业数据与语义边界内工作
Policy / Governance	解决：Agent 到底有没有资格做这件事

这五块拼起来，才接近所谓的 AI-native enterprise workflow。但这里必须停一下，因为上面的材料对不同的目标会给出相反的答案。它既能支持“BPMN 该退休”，也能支持“BPMN 是合同层”。问题不在材料，在于目标没有定清楚：我们讨论的到底是 Agent Platform，还是企业业务流程？

Layer 1：Business Process

这个可以继续使用：

BPMN
Camunda
Fluxnova
SAP workflow
ServiceNow

解决合规、审批、SLA、责任、审计和跨部门流程。例如：开户 → KYC → Risk → Approval → Account Creation。

Layer 2：Agentic Workflow

这完全不同。例如：

具体是 Goal 先到 Research Agent，再扇出 Search / Read / Compare / Calculate / Ask specialist / Re-plan / Verify 七路。

这套能力由 Agent Framework、Execution Runtime、Policy、Memory、Tool Runtime 和 Durable State 实现：

Agent Framework
Execution Runtime
Policy
Memory
Tool Runtime
Durable State

分开看：对 Agent Platform，与对企业业务流程

传统方式	Agent 时代对应物
BPMN Process	Execution Policy / Task Model
Gateway	Policy / Agent Decision
Service Task	Tool
Sub-process	Agent / Sub-agent
Human Task	Human-in-the-loop
Process Variable	Durable State
Process Instance	Agent Run
BPMN Engine	Agent Execution Runtime
DMN	Policy / Rules Engine
Process Monitor	Agent Observability
Process History	Event / Trace
Workflow Designer	Code / DSL / AI-generated Plan
Static Flow	Dynamic Execution Plan

由此可以给一个更精确的说法。一种常见的表述是“老的那套 Camunda / Fluxnova，甚至所谓 Low-code 产品，都不该再用”，这个判断要分两种情况看。

对 Agent Platform 本身，基本正确。

不要把 Camunda / Fluxnova / BPMN 当成核心抽象。

对 Enterprise Business Process，则不正确。

BPMN 这些东西仍然很有价值，因为法律责任、合规、审批、SLA、审计、跨系统 transaction 和 human accountability 并不会因为 LLM 出现就消失。所以真正可行的架构是下面这一层组合，前两种做法都不行：

Business Process Layer + Agent Execution Layer

两者之间通过 typed task / events / policy / authority / durable state 连接。

从零设计一个 Agent Platform 时，应该先建什么

第一步不该是建 Workflow Designer，而应该先建这 7 样东西：

1. Agent Runtime
1. Durable Execution Runtime
1. Tool / MCP Gateway
1. Policy & Authority Engine
1. Context / Memory Runtime
1. Human Task Runtime
1. Trace / Evaluation / Audit

然后再决定哪些地方需要 BPMN，哪些地方需要 Graph，哪些地方完全由 Agent 动态决定。先选 Camunda 再想办法把 Agent 塞进去，顺序就反了，这才是真正的 AI-native workflow architecture。另外，Google、Microsoft、LangGraph、Temporal 当前都在把 workflow 做成 code/runtime-first 的 graph + state + durable execution，而不是继续强化传统“业务人员拖节点”的范式；这已经不是单个厂商的偶然选择。(GitHub)把这个结论落到 “内部 LangChain DeepAgents + AWS AgentCore + LangSmith 的 AI 能力平台” 上，下一步最值得做的是设计一套 Agent Runtime / Execution Runtime / Business Process 三层架构，并把 Temporal、AgentCore、LangGraph、Microsoft Agent Framework、Camunda/Fluxnova 放进去逐项对比。这样才能比较清楚地判断一家平台到底应该自己做什么、买什么、哪些东西根本不该引入。把范围从厂商文档扩大到四类证据——学术研究、模型厂商实践、企业 AI 平台、金融机构与监管机构的实践——结论会更完整：2026 年真正成熟的方向，不是“把 BPMN 换成 Agent”，而是把 Workflow 拆成“Agentic Decisioning + Durable Execution + Policy/Authority + Enterprise Ontology/Data + Evaluation”。对通用 Agent 平台而言，传统 Workflow 仍然存在，但它越来越像受约束的外围控制面，而不是平台的核心抽象。

这五块各自最值得追的线索，按调用顺序是：Agent Harness → Agent Orchestration → Durable Runtime → Ontology / Data / Tools → Policy / Identity → Human Control → Audit / Evaluation，有前景的企业平台大概率会把它们组合。

趋势阶段的金融分层

趋势阶段常见的一种画法，是把 Experience、Agent、Control、Runtime、Semantic、Tools 六块并列展开。那张图不能算错，但它还没有回答本文真正关心的问题——业务状态归谁、Agent Task 的边界由谁定义。本文最终的主线架构（第 25 节）会把这两件事补上，因此这里不再重复贴图。只需要先记住其中一个判断：Ontology / Semantic Layer 和 Agent Runtime 是两个不同东西。Palantir 最强的是前者，AWS / Microsoft / OpenAI / Anthropic 最强的是后者，而 Snowflake 正在试图把 Data + Semantic + Agent Runtime 放在一起。

趋势阶段的结论

回到最开始那个判断：“老的 Camunda / Fluxnova，甚至所谓 Low-code，都不应该再用。”把论文与各家厂商、监管机构的材料串起来看之后，这个说法要修正得更精确。

错误方向

错误方向是 BPMN → LLM Node → Agent 的串法。

这确实不是最有前景的 Agent Platform 架构。

同样错误

User 到 Autonomous Agent 再到无限 Tool 直达 Enterprise 的做法：User → Autonomous Agent → 无限 Tool → Enterprise。金融领域尤其不可接受。

更合理的 2026+ 模型

对通用 Agent 平台而言，一句话概括：未来的 Workflow 不是“下一步去哪”，而是“Agent 为了完成 Goal，可以在什么边界内，以什么权限，持续做什么，并且如何被暂停、恢复、验证和追责”。而 Palantir Ontology 解决的是“世界是什么、能对世界做什么”；Anthropic/OpenAI Harness 解决的是“Agent 如何工作”；Microsoft/Temporal/AWS 解决的是“Agent 如何可靠地长期运行”；Snowflake/Google 解决的是“Agent 如何在企业数据与语义边界内工作”；Policy/Governance 则解决“Agent 到底有没有资格做这件事”。这五块拼起来，才比较接近 AI-native enterprise workflow。而金融服务真正应该研究的核心不是“哪个 Workflow Engine 最好”，而是：

Agentic Decision + Enterprise Ontology + Durable Execution + Authority + Evidence

这比单纯讨论 Camunda、Temporal、LangGraph 谁替代谁，层次高一个级别。

2026：Workflow Engine 与 Agent Runtime 正在合流

上面列出的厂商如果并排看，会发现它们在做同一件事，只是起点不同：AWS 的 Step Functions 直接调用 AgentCore Harness（Amazon Web Services, Inc.）；Camunda 把 Agent 建模成流程里的一等执行对象（Camunda 8 Docs）；Microsoft 让同一套 workflow 定义换个 host 就获得 durability（Microsoft for Developers）；Google 把 Agent Runtime 与 Durable Execution 打包成 Agent Executor（Google Cloud）；Temporal 则让 Agent Loop 直接跑在 durable Workflow 里（Temporal）。

合流的是运行时能力，不是业务语义。准确的说法是 Workflow、Agent Runtime、Durable Execution 是三种不同的架构责任，而未来的产品会越来越把它们组合在一起：

flowchart TB
    BP["Business Process"]
    AW["Agentic Workflow"]
    DE["Durable Execution"]
    GOV["Policy / Authority"]
    DATA["Enterprise Data / Ontology"]
    ACT["Controlled Action"]

    BP --> AW
    AW --> DE
    BP --> DE
    AW --> DATA
    AW --> GOV
    BP --> GOV
    GOV --> ACT
    BP --> ACT

对金融企业而言，这意味着选型问题要换一种问法：不再问“买 BPMN 引擎还是买 Agent 平台”，而是问这三种责任在哪里合并、在哪里隔离——业务编排必须留在确定性的 Business Workflow 里，Agent 的执行可以交给合并后的 Runtime，但状态归属、审批与举证不能跟着一起合掉。后面的第四、五部分就是这道划分题的答案。

第三部分：金融为什么不能照搬

第二部分介绍的四个领域，都是通用企业场景下的正确答案。金融场景多出来的主要不是技术难度，而是举证责任。这一部分说明的是：金融到底额外要求了什么，以及这些要求如何反过来决定架构。

18. 金融真正担心的问题：Verifiability Gap

通用企业场景里，最常被讨论的问题是“Agent 够不够聪明”，金融业担心的则是 Agent 到底代表谁行动，这个问题在金融业特别严重。最新一篇关于 Agentic AI governance in FinTech 的研究提出了 Verifiability Gap，也就是说：Agent Authority → 实际执行 → 能否证明：为什么当时允许它这么做？这项研究把 orchestration 本身看作 policy layer，并指出以下几点：

orchestration 本身是 policy layer
不同 orchestration 结构会改变最终决策
historical replay 可能无法重现
model/version变化会改变结果
deterministic replay 并不等于 historical decision replay (arXiv)

传统 Workflow：same input → same BPMN → same path。 Agent：same input → different reasoning → different tools → different context → different outcome。所以：

Agent Workflow 的审计对象不能只是“流程图”，而必须是 Execution Trace + Context + Authority + Evidence。

19. 监管机构在看什么

Bank of England

2026 年 Financial Stability Report 已经专门讨论 Agentic AI，其中提到目前金融机构主要使用 Agent 做 research、coding、surveillance 和 lower-risk operations，而不是 autonomous trading。核心风险在于 output 不可预测、validation 困难、autonomy boundary 难定义，以及 correlated behavior (Bank of England)。

FSB 2026：12 类 sound practices

Financial Stability Board 2026 年 AI governance consultation 提出了 12 类 sound practices，覆盖 AI governance、lifecycle management、risk identification、operational resilience、third-party dependence，以及 GenAI / agentic AI risks (Financial Stability Board)。这说明金融监管未来看 Agent，除了 model risk，还要看：

Model
Agent
Tool
Data
Permission
Runtime
Vendor
Human Oversight

20. 已经跑在生产上的样本：Stripe 与 AWS

Stripe

AWS 与 Stripe 2026 年公开的案例很有参考价值，场景如下：金融合规 review Stripe 面临：thousands of transactions / day 它搭建 production agent system：Agent → AWS Bedrock → enterprise data → compliance reasoning → human review。公开结果如下：

review handling time ↓ 26%
helpfulness >96%
final decision 仍由 human 控制 (Amazon Web Services, Inc.)

Stripe 并没有让 Agent 直接取代 Compliance Officer，它真正做的是：

Agent = investigation / preparation
Human = decision authority

这是当前金融服务中较容易同时满足治理、审计与责任要求的一种落地模式。把它写成“未来几年的主流架构”属于过度推断——监管材料描述的是当前的风险与实践，不足以证明未来的主流形态。

AWS 的金融 Agent 参考架构

AWS 2026 年的 Financial Services AgentCore 架构如下：

具体是 Agent 扇出 Market / Risk / Research 三个 Specialist，经 Orchestrator 进 AgentCore Runtime（Identity / Tracing / Sandbox），Identity 之下再挂 Policy。

例如 portfolio advisory 包括 portfolio valuation、risk stress test、market research 和 advisor synthesis，由多个 specialist agents 协同完成。(Amazon Web Services, Inc.)

而信用分析案例则是：

Policy PDF
Snowflake account history
transaction patterns
Agent reasoning
recommendation

这非常接近企业真正的 Agent Workflow。(Amazon Web Services, Inc.)

AWS 的新方向：Step Functions 直接调用 AgentCore

2026 年 6 月 AWS 把上面这件事又往前推了一步：Step Functions 可以直接调用 Bedrock AgentCore Harness，把 Agent 当成 Workflow 中的一等步骤。Step Functions 管 workflow execution，AgentCore 管 agent loop；多个 Agent 可以并行或串行出现在同一个流程的不同决策点，关键动作前可插入 human approval；workflow execution history 里直接能看到每次调用的 agent input、output、token 用量与 duration，session ID 让 Agent context 可以跨 workflow execution 保留。(Amazon Web Services, Inc.)

这里已经不是“Workflow 和 Agent 二选一”，而是 Workflow Engine 调用 Agent Runtime——与本文第四、五部分的主线结论是同一件事。

21. 金融 Model Risk Management 里的 Agentic Workflow

这一节看金融领域的实证研究。它们没有停在“客服 Agent”这类演示场景上，而是直接落在信贷、反欺诈和模型风险管理上——比通用的 Agent 案例更接近企业真正的问题。2026 年有一篇比较完整的 survey 覆盖了以下方面：

Agentic Artificial Intelligence in Finance: A Comprehensive Survey

涵盖 financial operations、financial markets、architecture、regulation、systemic risk 和 multi-agent coordination (arXiv)。

另外一篇论文的内容如下：

AI Agents in Financial Markets

它把金融 Agent 拆成以下结构：Data Perception → Reasoning → Strategy Generation → Execution + Control。它的结论是短期最可能的形态不是 fully autonomous finance，而是 bounded autonomy，即：

AI
human supervision
constrained execution

这对企业架构有直接影响。(arXiv)

另一项研究做了以下组合：

Modeling Crew
Model Risk Management Crew

例如：

Manager Agent] —> E1[EDA Agent：

另一组：

MRM Manager] —> A1[Compliance Agent：

该研究在 fraud detection、credit approval 和 credit risk 中做了实验 (arXiv)，这比“客服 Agent”更接近企业真正的问题。

22. 金融服务真正需要确定下来的六件事

把前三部分的材料压成六条，就得到金融服务对架构的硬约束。它们不是设计偏好，而是监管、责任和事故成本直接推导出来的结果。

#	约束	为什么	在架构上的落点
1	确定性	结论必须能从输入与规则推导出来	Workflow Runtime 持有状态转移
2	责任	每个决策必须有人签字	Human Task + Identity
3	审批	高风险动作不能自动生效	BPMN + Policy
4	审计	事后必须能回答“谁做了什么”	Audit Trail
5	授权	“能做”和“被允许做”是两件事	IAM + Agent Policy
6	可追溯	结论与证据要对得上	Evidence + Agent Trace

这六条之外，还有一条从 Verifiability Gap 直接推出来、但容易被低估的要求：可复现性（reproducibility）。传统的可复现假设是“同样输入 + 同一个流程版本 = 同样结果”，Agent 打破了这个假设：同样的输入，可能因为不同的检索结果、不同的上下文、不同的模型版本，得到不同的推理路径和结论。所以在金融场景下必须退一步，先明确自己能承诺哪一种复现：

Level A：完全可重放：同输入 + 同模型 + 同工具 + 同上下文快照 → 同结果
Level B：可复核：同业务事实快照 + 记录在案的规则版本 + 记录在案的 Agent 轨迹 → 人可以独立得出同一结论

大多数业务应该按 Level B 设计，把 Level A 留给真正需要法律级举证的动作。这个决定必须在架构设计阶段做，事后基本补不上——因为它决定的是要不要保留业务事实快照、规则版本和完整 Agent 轨迹。等审计来问的时候再补，通常已经晚了。这六条约束加上可复现等级，就是后面架构设计的全部输入。但注意这些约束只决定 Business State 与 Process Authority 必须有人拥有，不意味着所有认知工作都必须 BPMN 化——第 7 节那种纯 Agent 任务同样要过这六条，只是由不同的 Runtime 来承担。

金融领域可以借鉴的形态

金融领域可以借鉴的形态，同样不是把 Agent 放在整个流程之上，而是：

即 Domain Agent 经 Financial Context Layer（Ontology / Policies 与 Research 文档 / Structured Data）与 Dynamic Planning，进 Durable Agent Runtime（Policy / Authority、Tool Gateway、Human Approval），Tool 接 Core Banking / Trading / CRM / Risk 与外部数据，产出 Evidence + Trace 进 Audit。

第四部分：架构决策——谁拥有 Orchestration Authority

23. 全文原则

前面十二节都是趋势观察。趋势观察的结论会随着“目标是什么”而改变：目标是通用 Agent 平台，还是金融企业的业务流程，答案可以完全相反。

从这一节开始，目标明确为后者：金融服务中确定性业务流程的落地架构。在这个前提下，前面那些材料会收敛出一条比两者都更窄、也更可执行的主线。

把“业务分析师能够把大部分流程梳理清楚”这个前提补上之后，前面的结论需要调整：对于金融服务，BPMN 不应该被淘汰。如果业务分析架构师能够把大部分业务流程、状态、审批关系、异常路径、职责边界都分析清楚，那么 BPMN/DMN 反而仍然是最合适的“业务控制平面”。真正要改的不是“有没有 Workflow”，而是分工：不要让 BPMN 承担 Agent 的智能行为，也不要让 Agent 取代 BPMN 的确定性业务控制。于是新的架构可以定义为：

Deterministic Business Workflow + Bounded Agentic Execution

也就是：

业务流程确定性
Agent 局部智能化
统一 Policy / Authority
统一 Audit / Evidence

这实际上比“纯 Agent Workflow”更适合银行、保险、资管、证券。

先定下一条原则

在展开这一部分之前，先把本文反复使用的那条原则定下来：

任何 Agent 驱动的业务动作，在产生业务状态变化或外部副作用之前，都必须经过确定性的 schema / business validation 与 authorization；是否需要 Human Approval，由 BPMN 与 Policy 按风险等级决定。

这句话里有三个从句，各自解决一个问题。“必须经过确定性验证”保证进入流程的不是一段自然语言，而是一个可校验的结构，这是后面 Task Contract 里 output schema 存在的理由。“必须经过 authorization”保证“Agent 有能力做”和“Agent 被允许做”永远是两件事，前者是模型能力问题，后者是治理问题。“是否人工批准由风险等级决定”避免两个极端：既不要求所有输出都过人工（那等于退回 Level 0，自动化失去意义），也不允许高风险动作走自动通道。后面第 38 节会说明，为什么这条原则必须同时覆盖“建议型输出”和“动作型输出”这两种 Task——只写一半，就会在评审时被抓出漏洞。

24. 两类问题：业务怎么走，和某一步怎么完成

在这个场景下，整个系统可以拆成两个完全不同的问题：

问题 A：业务应该怎么走？

由以下结构确定：Business Architect → BPMN / DMN → Workflow Definition。包括状态、顺序、并行、条件、审批、角色、SLA、回退、异常、补偿和业务事件，这些尽量确定。

问题 B：某一步里面具体怎么完成？

这里允许 Agent，例如：Compliance Review → Agent：找政策 / 找历史案例 / 找相关文件 / 检查证据 / 总结风险 / 提出建议 → Human → Approve / Reject。因此，BPMN 决定“做什么、谁做、何时做、结果去哪”，Agent 决定“这一项任务怎么做得更好”，这是整个设计的边界所在。

Workflow 管的是状态转移与业务责任

在前面那套分层里，有一个界定需要修正。原来是 Workflow 管 State + Action，在这个前提下，应该修正为 Workflow 管 State Transition + Business Responsibility，也就是：BPMN → State → Task → Business Rule → Next State。而 Agent 是：Task → Agent Execution → Structured Result。 Agent 不拥有 Workflow。

25. 五层架构

把前面的分层和这里的约束合起来，得到本文的主线架构，也是全文唯一一张完整架构图。后面所有图都是它的局部展开。

flowchart TB
    BA[Business Architect]

    subgraph BP["Business Process"]
        BPMN[BPMN / DMN]
        SLA[Roles / SLA / Approval]
    end

    subgraph WR["Workflow Runtime"]
        State[Process State]
        Tasks[Human / System / Agent Task]
        Events[Timer / Event]
    end

    subgraph AR["Agent Runtime"]
        Contract[Agent Task Contract]
        Harness[Harness / Planning]
        Tools[Tools / MCP]
        AgentState[Agent Task State]
    end

    subgraph DS["Data & Semantic"]
        Data[Business Data]
        Ontology[Ontology / Knowledge]
    end

    subgraph GOV["Control"]
        IAM[IAM / Authorization]
        Policy[Policy / Guardrails]
        Evidence[Evidence / Trace]
    end

    BA --> BP
    BPMN --> WR
    WR --> Tasks
    Tasks --> Contract
    Contract --> Harness
    Harness --> Tools
    Tools --> DS
    Harness --> Policy
    Tools --> IAM
    Harness --> Result[Structured Result]
    Result --> Validate[Validation]
    Validate --> WR

这张图里关键的关系是 Workflow Runtime 创建并控制 Agent Task，Agent Runtime 负责完成这个 Task，也就是第 33 节说的 Agent-in-Process。同样关键的是右下角那条回路：Agent 的输出必须先过 Validation 与 Authorization，再经过必要的人工批准，最后由 Workflow Runtime 落成状态转移。Agent 在这个回路里始终是提议方，不是决定方。

五层各自回答什么

层	回答的问题	失败时的典型表现
1. Business Process Plane	流程应该怎么走	流程只存在于文档和人的记忆里
2. Workflow Runtime	这个 case 现在在哪一步	状态散落在业务表里，没有人能统一回答
3. Agent Execution Plane	这一步怎么完成	每个团队各造一套 harness
4. Data & Semantic Plane	Agent 看到的是哪一个版本的事实	同一个指标三个数，结论无法复核
5. Control Plane	谁被允许做什么	“Agent 有权限”成了唯一的安全声明

为什么是五层，而不是四层

常见的一个版本把 IAM / Policy / Audit / Evidence / Data 全部放进同一个 Enterprise Control Plane，这会在两个地方出问题。第一，Data 不是控制：

平面	回答
Data / Semantic Plane	回答：世界是什么样
Control Plane	回答：谁被允许做什么

两者放在一起，会导致“数据权限”和“数据语义”被混为一谈：访问控制做到位了，但 Agent 依然不知道 Position 和 Portfolio 是什么关系，前者是安全问题，后者是能不能正确工作的问题。第二，Evidence 也不是控制。Evidence 是某一次具体执行产生的产物，它天然属于执行侧，只是在最后被 Audit 引用，把 Evidence 放进 Control Plane，会让它看起来像一个统一存储，而不是每一次 Task 都必须产出的东西。它应该在另一个三层关系里被定位：Audit 记录主体，Evidence 记录依据，Trace 记录过程——也就是第 31 节要展开的内容。所以最终是五层：Process / Runtime / Agent Execution / Data & Semantic / Control。

26. 展开图：数据与治理怎么接进来

这是第 25 节那张主线架构在数据与治理侧的展开。

27. 每一层解决的问题与最适合的技术

层	解决的问题	最适合技术
Business Process	流程应该怎么走	BPMN
Business Rules	什么条件成立	DMN / Rule Engine
Workflow Runtime	如何可靠执行	Camunda / Temporal / Durable Runtime
Agent Runtime	如何智能完成任务	Agents SDK / LangGraph / DeepAgents
Policy	谁可以做什么	IAM / Policy Engine
Human Approval	什么风险由人承担	Human Task / Approval Matrix
Data	企业事实是什么	Snowflake / DB / Ontology
Audit	发生了什么	Activity Log / Trace / Evidence

这样也不会再问“是不是 Agent 出现以后，BPMN 就过时了”，BPMN 并没有过时，变化的是职责划分。

28. 责任矩阵

第 25 节回答了“分几层”，第 27 节回答了“每层适合什么技术”，这一节回答最后一个问题：每一件事由谁负责。落到具体条目上，会得到一张可以直接进评审会的表：

问题	谁负责
流程走哪	BPMN
业务条件是什么	DMN / Rules
当前业务状态是什么	Workflow Runtime
谁负责这个 Task	Workflow / IAM
Agent 能看到什么	Context / Data Policy
Agent 能用什么	Tool / Capability Policy
Agent 如何完成任务	Agent Runtime
Agent 得到了什么	Structured Result
是否符合业务规则	Validation / DMN
Agent 能不能执行	Authorization / Policy
是否必须人工批准	BPMN + Policy
业务状态能否改变	Workflow Runtime
为什么这么做	Evidence
谁什么时候做了什么	Audit
Agent 如何做的	Agent Trace
模型是否可靠	Evaluation
当时的业务事实是哪一版	Business Data Contract

这张表把“Agent 到底能不能自主”这类争论，拆成了十几个可以逐条达成一致的问句，例如讨论“要不要让 Agent 自动审批”，真正需要确认的只是其中第 4、10、11 行，而不是重新设计一遍流程。

29. 五件容易混在一起的事

“确定性”不等于“只有一张流程图”。在金融场景里，有五类判断，各自必须落在不同机制上。把它们合并成一句“业务规则和权限合同”，是架构评审里最常见的返工来源。

这里有一个必须先纠正的说法：Business Rule 和 Authorization Policy 不是同一类 policy。“投资金额超过 1 亿就需要高级审批”是业务规则，“这个角色有没有投资审批权”是授权。前者判断“条件是否成立”，后者判断“主体有没有资格”。两者都常被写成 policy 配置文件，但变更流程、评审人与举证对象完全不同——业务规则由业务方改，授权由安全与内控改。把两者放进同一套配置里管理，是金融场景里最容易埋下隐患的一种简化。

BPMN：流程怎么走

哪里需要审批
什么条件下回到上一步
哪一步可以并行
什么时候结束

它回答的是状态转移。

DMN / Business Rules：业务条件怎么判断

investmentAmount大于100M → seniorApprovalRequired

它回答的是条件是否成立，而且这个判断是可枚举、可回归测试的。

Authorization / IAM：谁有权执行

PM_ROLE
Investment_Approval
Portfolio_X

它回答的是主体资格。同一条流程，不同角色能按的按钮不一样，这是权限问题，不是规则问题。

Agent Policy / Guardrails：Agent 可以调用什么

canRead: market_data, research_db
canWrite: draft_report
forbidden: customer_pii_export
maxBudget: { tokens: 100000, toolCalls: 50 }

它回答的是这个 Agent 的能力边界，与“这个人有没有资格批准”是两件事。

Human Approval：什么风险必须由人承担

riskLevel GE HIGH → humanApprovalRequired
agentConfidence LT threshold → humanApprovalRequired
amount GT limit → humanApprovalRequired

它回答的是责任归属，前四类都是机制性的判断，只有这一类是把责任落到具体的人身上。金融机构做 Agent 立项时，真正需要业务方逐条签字确认的往往就是这张表，而不是流程图本身。

五者关系：

五条线汇入同一个执行前的判定（BPMN 讲流程怎么走、DMN 讲条件是否成立、Authorization 讲谁有权、Agent Policy 讲 Agent 能用什么、Human Approval 讲什么风险由人承担），再到执行 / 拒绝 / 转人工。

金融场景里这五条不能合并，原因是审计时它们的举证对象不同：

BPMN 举的是流程版本；
DMN 举的是规则版本与输入；
IAM 举的是主体与授权记录；
Agent Policy 举的是能力声明与实际调用日志；
Human Approval 举的是审批人身份与审批当时的判断依据。

混在一起，事故复盘时就无法归因——你只能证明“当时有这个流程”，但不能证明“当时这个动作是被允许的”，更不能证明“当时是谁承担的”。

边界：哪些判断必须留给规则

这条边界应该画得很严，例如：

适合 BPMN/DMN

Investment amount > 100M → Senior PM approval
High-risk country → Compliance mandatory
Product type = Derivative → Risk review mandatory

这些全部是确定性的。

适合 Agent

这个公司披露的信息有没有前后矛盾？
这份研究报告是否遗漏了重要风险？
这个交易是否存在异常模式？
这份申请材料是否足以支持该结论？
相关政策中是否存在需要特别注意的条款？

这些很难纯规则化。

因此可以这样划分：

Deterministic → BPMN / DMN
Semantic / Investigative → Agent

这是比较实用的边界。

三层决策架构

三层形成闭环：Layer 1（Deterministic Business Flow）→ Layer 2（Deterministic Business Rules）→ Layer 3（Probabilistic Agent Reasoning）→ Validation / Policy Gate → 回到 Layer 1。

Layer 1：BPMN

回答流程走哪里。

Layer 2：DMN / Policy

回答什么情况下允许。

Layer 3：Agent

回答如何分析这个复杂问题。

再回到：Policy / BPMN 形成闭环。

BPMN 反而会变得更简单

传统 BPMN 经常被迫表达大量业务逻辑。Agent 出现以后，反而可以把：“需要智能判断” 封装成：Agent Task 比如：Compliance → 13个 Gateway → 37个条件 → 8个子流程。现在：Compliance → Agent Review → Human Decision。但不能把所有东西扔给 Agent，DMN 继续负责明确业务规则。因此更合理的分工如下：

BPMN：Flow、Role、State、Approval、Task
DMN：Eligibility、Threshold、Risk classification、Approval matrix
Agent：Investigation、Interpretation、Evidence discovery、Recommendation

三者职责很清楚。

30. Workflow 形态的正交分类

前面有一版分类把 Workflow 分成四种：Deterministic、Agentic、Policy、Human，这个分类不建议保留，原因不是它错，而是这四项不在同一个分类维度上：Deterministic / Agentic 描述的是执行方式，Policy 描述的是控制方式，Human 描述的是参与者。它们并不互斥，同一条流程里同时出现 Agent Task、Policy Gate 和 Human Approval 是常态：BPMN Workflow → Agent Task → Policy Gate → Human Approval。于是同一条流程按旧分类会同时属于四类，分类就失去了判别力，更严谨的做法是拆成三个正交维度：

Dimension	Values
Execution	Deterministic / Bounded Agentic / Dynamic Agentic
Task	Human / System / Agent / Hybrid
Control	Rule / Policy / Human Approval

其中 Execution 指谁决定下一步（Deterministic 由 Process Definition 定，如 Settlement；Bounded Agentic 由 Agent 在预先定义的边界内定，如 Compliance Review；Dynamic Agentic 连下一步都由 Agent 定，如“调查这家公司是否值得投资”）；Task 指谁执行（金融场景最常见的是 Hybrid：Agent 准备决策包，Human 批准）；Control 指凭什么放行（Rule / Policy / Human Approval，对应 Agent wants to act → Authorization → Risk classification → Approval → Execute / Reject）。

以本文后面那个投资 Idea 流程为例：

Investment Idea Review
= Deterministic（主流程）+ Bounded Agentic（各 Review Task）
+ Hybrid
+ Rule + Policy + Human approval

这个描述可以直接进设计文档，而“四种形态”不能——因为它无法回答“这条流程属于哪一类”。

31. Audit、Evidence、Agent Trace 是三件不同的事

这三个词在讨论里经常被并列甚至混用，但它们回答的是三个不同的问题，取证方式和保留策略也不同：

flowchart LR
    Task["Agent Task"]
    Task --> Audit["Audit：谁 / 何时 / 做了什么"]
    Task --> Evidence["Evidence：依据了什么"]
    Task --> Trace["Agent Trace：怎么完成的"]

类型	回答什么问题	特征
Audit	谁、何时、做了什么	主体是人和流程，与模型无关，保留期由监管定
Evidence	依据了什么	主体是业务事实来源，决定结论能否被复核
Trace	Agent 怎么完成	主体是执行过程，用于评估调试，保留期较短

一个实际后果是只保留 Audit，复盘会变成“流程没错，但结论不对”；只保留 Trace，则无法回答“当时是谁批准的”。两者都要，并且必须通过同一个 Task ID 串起来，这也是 Task Contract 里 audit.traceLevel 这个字段存在的意义。

32. Agent Runtime 与 Business Workflow Runtime 是不同的 Orchestration 层

“Agent Runtime 不是 Workflow Engine”这个说法需要修正：Microsoft Agent Framework 本身就具有 Workflow Runtime，LangGraph 也有 durable execution、checkpoint / resume 等能力。更准确的是：Agent Runtime 可以实现 Agent Workflow，但不等于 Business Workflow Runtime。架构是：BPMN Engine 之下挂 Human Task、System Task 与 Agent Task，Agent Task 之后进 Agent Runtime（Tools / Context / Memory）。

BPMN Engine

负责 execution、state、task、routing、timers、events、retries、SLA 和 human workflow。

Agent Runtime

负责 reasoning、tool use、context、memory、planning 和 evidence gathering。

两者边界很干净。

三种编排模式

Model A（纯 Business Workflow）：BPMN → Workflow Runtime → Tasks。
Model B（纯 Agent Workflow）：Agent Goal → Agent Workflow → Tools / Human / Subagents。
Model C（Nested）：BPMN → Agent Task → Agent Workflow → Structured Result → BPMN。

金融不是默认选择 C，而是根据业务责任判断 A / B / C：金融主流程默认从 A 开始，复杂认知任务可以使用 B，当 A 和 B 同时存在时使用 C。

判断问题	Business Workflow	Agent Workflow	Nested
谁定义下一步	Process Definition	Agent	外层 + 内层分别定义
Business State	核心	非核心	外层
Agent Working State	非核心	核心	内层
业务角色 / SLA	核心	通常外置	外层
动态规划	弱	核心	内层
Multi-Agent	辅助	核心	内层
流程版本治理	核心	Code / Graph version	两层分别版本
合规责任	强	需要额外构建	外层
业务人员可读性	强	弱	外层强
模型更换对流程影响	小	大	外层隔离
适合金融主流程	高	通常不作为主流程	最高
适合复杂认知任务	中	高	最高

33. “Agent-in-Process”而非“Process-in-Agent”

这两个名字很形象。不推荐 Process-in-Agent，即让 Agent 决定整个 Business Process，风险很大。推荐 Agent-in-Process，即 Business Process 之下是 Agent Task，Agent Task 之后才是 Agent，符合金融机构对 predictable、controllable、explainable 和 auditable 的要求。

不推荐

Process-in-Agent，风险很大。

双向调用：Agent 也可以调用受治理的 Workflow

上面讲的是 Workflow 调用 Agent——这是金融主流程的方向。但 2026 年的产品已经出现了反方向：Agent 调用受治理的 Workflow。Camunda 8.10 的 Processes MCP Server 会把已部署的流程自动注册成 MCP tool，Agent 可以直接发现并调用（传参进去，新起一个 process instance，拿回 instance key），不需要在 Agent 框架与流程引擎之间另写集成层。(Camunda 8 Docs)

Business Workflow → Agent Task → Agent Runtime → 受治理的 Sub-workflow → Workflow Runtime

所以未来更准确的模型不是单向嵌套，而是双向调用：Workflow 把 Agent 当一等步骤（如 AWS Step Functions + AgentCore (Amazon Web Services, Inc.)），Agent 把受治理的 Sub-workflow 当 Tool。但对金融主流程而言，方向仍以 Workflow 调用 Agent 为主——反方向只允许发生在有明确契约与审批的受治理子流程上。

34. 这套架构的名字，以及它为什么更容易治理

这套架构可以叫 Deterministic Core, Agentic Edge，在企业内部更贴切的说法是 Deterministic Business Process + Bounded Agent Execution。核心原则是 Deterministic Core 经 Agent Task 到 Agentic Edge，再经 Structured Result 到 Deterministic Validation。

这是比较适合金融服务的“新时代 Workflow”。

为什么它比“Agent Workflow”更容易治理

因为审计团队可以问：

“这个业务流程是什么？”

→ BPMN

“为什么这个 case 进入 Compliance？”

→ BPMN + DMN

“为什么 Agent 推荐这个结论？”

→ Agent Trace + Evidence

“Agent 为什么能调用这个 API？”

→ IAM + Policy

“为什么最终允许这个动作？”

→ Workflow transition + Policy

“谁最终批准？”

→ Human Task + Identity

整个责任链到这里是完整的。

第五部分：Agent Task Contract

35. BPMN 不应该描述 Agent 的内部过程

例如 Compliance Review，不要继续画成 Search Policy → Search Documents → Search Historical Cases → LLM Review → LLM Critic → Search Again → Summarize——这就走偏了。BPMN 只写 Compliance Review → Agent-assisted Review → Human Decision，Agent 内部 search → retrieve → reason → compare → identify gap → retrieve again → produce evidence → draft recommendation，这些属于 Agent Runtime，这是 Workflow 和 Agent 最重要的边界。

36. Agent Task Contract

Agent Task Contract 是本文的核心抽象。前面所有关于边界的讨论——流程归谁、状态归谁、权限归谁——最终都收敛到这个契约上。它很少直接给人看，主要作用是作为 BPMN 侧与 Agent 侧之间唯一需要对齐的接口。

两者的对应关系不是 Agent = Workflow，而是 BPMN Activity 落成 Agent Activity（完整链路见本节末 Validation Contract）。例如：

activity:
  id: compliance-review
  type: agent-task

  input:
    - investment_case
    - supporting_documents
    - compliance_policy

  output:
    - findings
    - evidence
    - recommendation
    - missing_information

  allowedTools:
    - policy.search
    - document.search
    - risk.lookup

  approval:
    required: true

这个 Activity 对 BPMN Runtime 来说仍然是一个普通 Task，只不过内部用了 Agent。

一份完整的 Agent Task Contract

把上一节那个 YAML 展开，一份可用的 Agent Task Contract 至少需要十一项：

agentTask:
  id: compliance-review
  workflow: investment-idea-review
  version: v3

  input:
    schema: InvestmentCase.v3
  output:
    schema: ComplianceFinding.v2

  capabilities:
    - policy.search
    - document.search
    - risk.lookup

  dataAccess:
    - investment.case
    - approved.documents
    - snapshot: ctx-20260912-1001

  instruction: compliance-review-policy v4.2

  execution:
    maxDuration: 15m
    maxToolCalls: 30
    maxTokens: 120000

  retry:
    maxAttempts: 2
    onFailure: escalate

  control:
    autoExecute: false
    humanApproval: required

  evidence:
    required: true
    citationRequired: true

  escalation:
    onLowConfidence: human
    onInsufficientEvidence: request_changes

  evaluation:
    criteria: compliance-finding-accuracy
    minConfidence: 0.8

  audit:
    traceLevel: full

逐项说明，以及缺了会怎样：

字段	作用	缺了会怎样
id / version	Task 身份与契约版本	流程升级后无法对应审计链
input / output schema	定义 Task 的输入输出类型	输出变成自由文本，无法进入流程
capabilities	允许调用的工具集合	Agent 可以调用未授权的能力
dataAccess	允许读取的数据范围与快照	Agent 看到不确定版本的事实
instruction	该 Task 使用的策略版本	无法解释某次决策依据了哪版规则
execution budget	时长、工具调用数、token 上限	成本与时长失控
retry / escalation	失败与低置信度时的去向	失败被静默吞掉，或无限重试
control	是否需要人工批准	高风险动作被自动执行
evidence	是否必须给出证据与引用	结论无法复核
evaluation	用哪套标准衡量质量	质量只能凭感觉
audit	轨迹粒度	出事故后无法复盘

这份契约真正的价值

它把两个以前混在一起的问题分开了：

BPMN 侧看到的是：一个 Task，有 ID、有输入、有输出、有 SLA、有审批
Agent 侧看到的是：一份边界声明，允许它在这个范围内自由决定怎么做

于是两边可以独立演进：流程改了，只要契约不变，Agent 不用动；Agent 换了模型或框架，只要契约不变，流程不用动。这就是“受约束的智能”的实际含义：自由度留在合约内部，责任留在合约外部。未来 Workflow Engine 和 Agent Runtime 真正连接的不是 LLM API，而是这份 Task Contract。

Validation Contract：提议如何变成状态变化

一份契约其实不够。Agent Task Contract 约束的是“怎么做”——输入输出、可用能力、数据范围、执行上限、审批模式、证据要求；而从提议到真正的业务状态变化，还需要第二份契约：Validation Contract。它只回答“能不能生效”：schema 校验、业务规则（DMN）、授权（IAM / Policy）、必要的人工批准。两份契约的分工，正好对应第 39 节那条管道的前后两半：

flowchart TD
    A["Business Workflow"] --> B["Agent Task Contract"]
    B --> C["Agent Runtime"]
    C --> D["Structured Result"]
    D --> E["Validation Contract"]
    E --> F["Workflow Runtime"]

Task Contract 管住 Agent 的自由度，Validation Contract 管住状态变化的生效条件，Workflow Runtime 管住最终落子。三份责任分开，事故复盘时才能逐段归因：结论错了查 Task 与证据，规则错了查 DMN 版本，放行错了查审批记录。

37. Agent 的输出必须结构化

这是金融领域必须坚持的一条，具体做法如下。

输出不采用以下形式：Agent → 一段自然语言。输出采用以下结构：

{
  "decision": "REQUEST_CHANGES",
  "findings": [
    {
      "type": "MISSING_EVIDENCE",
      "description": "2025 cash flow forecast missing"
    }
  ],
  "evidence": [
    {
      "documentId": "doc-123",
      "page": 17
    }
  ],
  "confidence": 0.91
}

这里需要先说明一个细节：confidence 是模型自报的数值，不应被当作业务可信度或风险评分使用。一个自报 0.91 的结论可能建立在残缺的证据上，一个自报 0.60 的结论也可能恰好正确——两者之间没有校准关系。如果架构上确实需要“置信度”，它应当由独立的验证或评估机制产生（例如多次 trial 的一致性、证据充分性检查、历史准确率），或者至少明确标注为“模型自评”，不允许直接进入流程判断。

Workflow Runtime 只接受：validated structured output 然后 BPMN 决定：REQUEST_CHANGES → Research。或者：APPROVE → Next Step。因此，Agent 提议业务状态变化，Workflow Runtime 决定它是否真的发生。更精确的表述见第 38 节：Agent 输出的是业务建议或动作提议，共同决定它的是 Workflow Runtime、Business Rule、Authorization 和必要的 Human Task。

38. Analysis Task 与 Action Task

有一个容易含糊的地方需要区分清楚：Agent 的“输出”到底指什么。在本文的模型里，Agent Task 分两类，它们的输出性质完全不同。

Agent Analysis Task

Agent 产出的是判断材料，其作用不含流程指令：

{
  "recommendation": "REQUEST_CHANGES",
  "findings": [
    { "type": "MISSING_EVIDENCE", "description": "2025 现金流预测缺失" }
  ],
  "evidence": [{ "documentId": "doc-123", "page": 17 }],
  "confidence": 0.91
}

它不应该输出 workflow transition。

即使字段名叫 recommendation，它的语义也只是“建议把流程导向 Request Changes”。真正决定是否回到 Research 的，是 BPMN 的网关、DMN 的规则，或者一个 Human Task。

把这两件事分开有两个实际好处：

Agent 的 prompt 里不再需要写“如果……就直接跳到第几步”，流程知识只存在一个地方；
BPMN 不依赖模型输出的语义，模型升级不会悄悄改变流程走向。

Agent Action Task

低风险场景下，Agent 可以提出一个动作提议：

{
  "action": "CLASSIFY_DOCUMENT",
  "target": "doc-123",
  "value": "quarterly_report",
  "confidence": 0.96
}

这个动作经过 policy 判断后可以自动执行，“可以自动执行”这个授权由 Policy 配置给出。

更精确的表述

于是前面那句“Agent 提议状态变化，Workflow 决定是否真的发生状态变化”，应该修正为：

Agent 输出业务建议或动作提议；Workflow Runtime、Business Rule、Authorization 和必要的 Human Task，共同决定这个提议是否能够产生业务状态变化。

这个表述多出来的部分（Business Rule、Authorization、Human Task），正是金融场景里最需要被明确归属的三个环节。少写一个，评审时就会被追问“那这里谁负责”。

39. Governed Action Pipeline

在金融 Agent workflow 里，任何 Agent 行为都可以统一看成一条 Controlled Action Pipeline——与 Agent 直调 API 的做法相比：

flowchart LR
    Agent["Agent"] --> Proposal["Proposal"]
    Proposal --> Validation["Schema / Business Validation"]
    Validation --> Auth["Authorization / Policy"]
    Auth --> Decision{"Human Approval?"}
    Decision -->|Yes| Human["Human Approval"]
    Human -->|Approved| Execute["Controlled Execution"]
    Decision -->|No| Execute
    Execute --> State["Workflow State Transition"]

这种方式安全和可审计得多。换句话说，即使 Agent 返回了 {"approved": true}，业务状态也不会因此自动改变——它只是一个提议，能否生效取决于后面的 Validation、Authorization 与 Workflow Transition。

为什么叫“管道”，而不是“事务”

这条链路上面那张图就是完整形态。它的语义是动作治理与授权：关心的是“这个动作有没有资格发生”。它不是分布式事务协议，也不涉及多个参与者能否原子提交的问题——把它套进事务语义去讨论，会让评审直接跑偏到错误的抽象层次上，去追问一个并不存在的协调者。

还有一点要写清楚：这条管道只负责把一个提议送达到“执行或拒绝”这个结论，它本身不产生业务状态转移。最终的状态转移仍然由 Workflow Runtime 依据 BPMN 完成，这也是整套架构里职责划分最干净的一条边界。

40. “审批”怎么处理

例如 PM Approval：BPMN: → PM Approval。内部可以：

Agent prepares recommendation → Agent highlights:
Agent highlights: → expected return
Agent highlights: → downside
Agent highlights: → risk
Agent highlights: → missing evidence
Agent highlights: → policy violations
Agent highlights: → PM
PM → Approve / Reject / Request Changes

PM 的按钮仍然是：

Approve
Reject
Request Changes

Agent 不能替 PM 点击，这正是 AI assistance ≠ AI authority 所表达的意思。

41. “修改”也由 BPMN 明确控制

例如：

Risk Review 按 Approve 进 Compliance、Reject 结束、Request Changes 回 Research。

这在 BPMN 中完全合理。

然后：Research → 修改材料 → Submit → Risk Review。这里 BPMN 描述的是确定性的状态转移规则；至于某个具体的 process instance 此刻处于什么状态，由 Workflow Runtime 持有。

不需要由 Agent 来决定“我觉得应该回到 Research”。

42. 什么时候允许 Agent 自己完成一个 Task

不用改 Workflow，只需要改变以下配置：Agent Authority Policy 比如：

agentAuthority:
  riskReview:
    canRecommend: true
    canApprove: false

  documentClassification:
    canRecommend: true
    canApprove: true

  investmentApproval:
    canRecommend: true
    canApprove: false

这样一来，Workflow 定义与 Agent autonomy 解耦，这种解耦让架构更稳定。

一个简单的三级模型

可以建立一个很简单的三级模型：

Level 0 — Human only

Agent → assist
Human → decision

Level 1 — Agent recommendation

Agent → prepare recommendation
Human → approve

Level 2 — Bounded automation

Agent → execute
Policy → validates
System → commits

金融机构前期绝大多数应该是 Level 1，部分低风险、重复性的任务可以做到 Level 2，Level 0 则用于真正高风险决策。

第六部分：一个完整的金融案例

43. Investment Idea Review 全流程

比如一个投资 Idea 流程（Draft → Research → Risk Review → Compliance Review → PM Review → Approved），业务分析师完全可以用 BPMN 表达。各 Review 环节按 Approve 进入下一步、Reject 结束、Request Changes 打回 Research，细节见下节三段式。

这里不需要消灭 BPMN，因为这个东西本身就是业务知识资产。

它回答了：

谁负责？
谁批准？
哪一步必须发生？
什么情况退回？
什么情况结束？
哪几个环节并行？

这恰恰是金融业务最需要确定性的部分。把这条流程展开，看每一段 Task 里 Agent 具体做什么、Human 具体决定什么。

Investment Idea Review

flowchart TD

    A[Idea Created] --> B[Research]

    B --> C[Risk Review]

    C -->|Approve| D[Compliance Review]
    C -->|Request Changes| B
    C -->|Reject| Z[Rejected]

    D -->|Approve| E[PM Review]
    D -->|Request Changes| B
    D -->|Reject| Z

    E -->|Approve| F[Approved]
    E -->|Request Changes| B
    E -->|Reject| Z

Research Task

Agent：

Search market data
Search company filings
Search internal research
Generate summary
Identify missing evidence
Draft thesis

输出：Research Package Human：

Submit
Request Changes

Risk Task

Agent：

Analyze financials
Calculate risk metrics
Compare peers
Identify anomalies

输出：

Risk Findings
Risk Recommendation
Evidence

Human：

Approve
Reject
Request Changes

Compliance Task

Agent：

Retrieve policy
Retrieve similar cases
Check restrictions
Identify missing documentation

Human：

Approve
Reject
Request Changes

PM Task

Agent：

Summarize entire case
Challenge thesis
Highlight risk
Compare alternatives

PM：

Approve
Reject
Request Changes

这里 Agent 能力很强，但它从头到尾都没有以下行为：

改变 BPMN
跳过审批
修改状态
自己批准

除非明确授权。

44. 投资研究：哪一段应该固化，哪一段必须留给 Agent

例如：

投资研究

第一次：Agent → search → SEC → research → valuation → competitor → analyst review。此时 Agent 很自由，跑了 5000 次以后发现：Company Financials → Peer Analysis → DCF → Risk Check → Report。这套路径已经高度稳定，那么这部分就可以固化为以下流程：compile → deterministic research workflow。而异常情况仍交给 Agent：

new company
unusual accounting
missing data
conflicting filings

需要强调的是，这里的“固化”并不意味着把 Agent 换成写死的代码，它的含义是把一个已经被反复验证过的子过程提升为确定性步骤：Company Financials → Peer Analysis → DCF → Risk Check → Report。而异常情况仍然交给 Agent：

new company
unusual accounting
missing data
conflicting filings

这里的分工标准是任务性质：

大部分可规则化的流程保持确定性；只有真正需要语义理解、调查、推理或动态工具选择的任务引入 Agent。

判断某个子过程是否到了可以固化的程度，判据是它是否稳定到“两个不同的人按同样的步骤会得出同一结论”。达不到这个标准的，继续留在 Agent 侧。

第七部分：每一层放谁

45. Workflow Engine 的裂解

过去，一个系统全部负责：Workflow Engine 未来更像：

Agent Platform：Agent Loop、Durable Runtime、Policy Engine
三者都进 Tool Layer，再到 API / MCP / Human。

而这些能力以前往往被归到同一个“BPM / Workflow”标签下：

Camunda / Fluxnova / ServiceNow → business process orchestration
Temporal / Durable Task → durable execution

把它们归成同一类，是选型时最常见的起点错误。

46. 能力 → 代表产品

前一版材料把行业归纳为“5 派”，那个分法把不同层次的东西并列了。按能力维度重新列一遍，选型时更不容易搞错：

能力	代表	定位
Business Process Orchestration	Camunda / Fluxnova	确定性流程、责任、审批、SLA、审计
Agent Workflow / Graph	LangGraph / Microsoft Agent Framework / Google ADK	Agent 侧的编排图、state、checkpoint
Durable Execution	Temporal / Durable Task	长时间运行、失败恢复、可重放执行
Managed Agent Runtime	AWS AgentCore / OpenAI Agents API / Snowflake Cortex Agents	托管 harness、sandbox、会话上下文
Enterprise Data / Ontology	Palantir / Snowflake	业务对象、语义层、动作模型

这张表要防的是三种常见误判。

误判一：把 Agent Workflow 和 Durable Execution 当成一类。

LangGraph 的 graph 与 Temporal 的 workflow 都在讲“编排”，但前者的产出是 Agent 的执行路径，后者的产出是可重放的执行历史。一个 Agent 图跑在 Temporal Activity 里是常见组合，但它们是两层，不是两个竞品。

误判二：把 Managed Agent Runtime 当成 Workflow Engine。

这是今年最容易出的错。托管运行时的“orchestration”指的是 Agent 内部的任务编排：决定先查什么、再调什么工具、什么时候停止。它不持有企业业务流程的状态，也不负责跨部门的审批与责任归属。

误判三：认为选了其中一层就等于有了整个架构。

这五层不是五个可选项，而是五个必须回答的问题。任何一层缺失，都会在落地时以事故的形式出现：

缺 Workflow Runtime → 审批与状态没有权威源
缺 Agent Runtime → 无法接入模型能力
缺 Durable Execution → 长任务在失败后无法恢复
缺 Managed Runtime → 每个团队自己造 harness 与沙箱
缺 Data / Semantic → Agent 看到的事实无法确定版本

反过来看选型问题会简单很多：不要问“谁替代谁”，要问“这一层谁来负责，以及层与层之间的契约是什么”。

再补一句：这张表是概念分层，不是产品分离。一个产品可以同时承担其中两层甚至三层——Microsoft 的 graph workflow 跑在 Durable Task 上，Temporal 的 durable Workflow 直接承载 Agent Loop，AWS 的 Step Functions 直接调用 AgentCore Harness。选型时真正要问的不是“买哪个产品替代另一个”，而是“这几份责任分别由谁承担”。

47. 换个选型维度：Control / Execution / Orchestration / Authority

不要再用“BPMN vs Agent”作为技术选型的第一维度。2026 年的产品已经证明，同一个厂商内部都同时提供确定性与动态两套东西，拿产品名当选型维度只会越比越乱。更实在的是四个决策维度：

维度	问什么	选项
Control Model	流程由谁决定	Deterministic / Goal-directed
Execution	跑多久、断了怎么办	Durable / Ephemeral
Orchestration	下一步怎么定	Static / Dynamic
Authority	谁承担责任	Human / Rule / Agent / Hybrid

按这个框架，前面几节的厂商各归其位：Camunda 是 Deterministic + Durable + Static/Dynamic + Human/Rule/Agent；Temporal 是 Code-defined + Durable + Static/Dynamic + Application-defined Authority；Microsoft Agent Framework 是 Graph + Durable Task + Agentic orchestration；AWS 是 Deterministic outer workflow + Agentic inner execution + Durable outer execution；OpenAI Agents API 是 Goal-directed + Long-running + Dynamic + Harness-controlled authority。

注意这与第 30 节的三个维度不重复：第 30 节是描述一条流程的三个正交维度（执行模型 / 任务模式 / 控制），这里是选型时的四个决策维度。两个表加第 46 节的能力表一起用：先用四个维度定方向，再用能力表定每一层谁来负责。

48. Camunda / Fluxnova 的合理位置

这一点与前面的结论有明显不同。如果企业的业务架构师已经大量使用 BPMN，并且企业已经具备：

BPMN 技能
流程资产
流程治理
审计模型
人员职责
流程设计规范

那么不应该建议抛弃 Camunda 一类的 BPMN Runtime，反而应保留以下定位：

保留 BPMN 作为 Business Process Control Plane。

然后把 Agent Runtime 接进来。

也就是说，选型不做二选一的对比：Camunda vs Agent 实际是两者相加：

Camunda
Agent Runtime

49. Palantir Ontology 的定位

在业务流程确定的前提下，Ontology 不应该取代 BPMN，它更适合做以下事情：

Business Objects
Relationships
Actions
Semantic Context

例如：

Investment
Portfolio
Security
Issuer
Risk
ComplianceRule
ResearchReport

然后 BPMN：什么时间做什么 Ontology：处理的业务对象是什么 Agent：如何理解和分析这些对象所以三者形成：

BPMN → Process
Ontology → Business World
Agent → Intelligence

这是一个很漂亮的组合。

50. 一个 AI 平台该怎么分层

更合理的做法是把架构重新分层，具体如下。以下做法不采用：Angular → Experience API → LangChain / DeepAgents → Camunda → Agent。采用以下分层：

flowchart TD
    APP[Applications] --> GW[Agent Gateway]
    GW --> AR[Agent Runtime]
    GW --> BAPI[Business API]

    AR --> CTX[Context]
    AR --> POL[Policy]
    AR --> PLN[Planner]

    CTX --> ER[Execution Runtime]
    POL --> ER
    PLN --> ER

    ER --> T[Tools]
    ER --> AG[Agents]
    ER --> HU[Human]

    T --> ES[Enterprise Systems]

各部分的分工是：

Durable Execution：Temporal / Durable Task
Managed Agent Runtime：AgentCore / OpenAI Agents API
Agent orchestration：DeepAgents / LangGraph / Microsoft Agent Framework
Observability + evaluation：OpenTelemetry / LangSmith / Foundry
Business process：Camunda / Fluxnova，只用在真正需要 BPMN 的企业流程上

第八部分：怎么落地

51. 不要重新造 Workflow Engine

如果企业已经有以下平台，优先复用：

Camunda
Flowable
Temporal
ServiceNow Workflow
自研流程平台

相比“又一个 Workflow Engine”，企业更缺的是以下几块：

Agent Task Runtime
Agent Governance
Evidence
Tool Gateway
Agent Evaluation

比如现有 Camunda：

Camunda：Human Task、System Task、Gateway、Timer、Agent Task；其中 Agent Task 进 Agent Platform。

这就已经足够现代。

52. 分阶段落地

Phase 1：先把确定性 Workflow 做好

BPMN
DMN
Human Task
State
Audit

先解决业务流程正确性问题。

Phase 2：Agent-in-Task

先给以下领域逐个增加 Agent Assistant：

Research
Risk
Compliance
Operations

这类助手重点放在以下几类能力上：

summarize
search
retrieve
analyze
draft
recommend

Phase 3：Bounded Agent Automation

对低风险 Task，走以下路径自动执行：Agent → Policy → Auto Execute。例如以下几类：

文档分类
数据校验
信息补全
标准化检查

Phase 4：动态 Agent Sub-process

只有在真正发现业务分析师根本没法把这一段流程事先定义清楚时，才引入以下形态：Agent-driven sub-workflow 而且这个动态部分仍然被一个明确的 BPMN Activity 包起来，执行路径如下：BPMN → Dynamic Agent Subprocess → Validated Result → BPMN。这样既不会阻碍 AI，也不会破坏金融业务的确定性。

第九部分：长期演进

53. Agent 负责探索，Workflow 负责固化

前面讨论的都是当前应该怎么设计，这一部分讨论的是长期演进，需要先把它的性质说清楚：这一节的结论是架构推论，不是论文结论。区分这一点很必要，因为它决定了这部分内容应该放在核心架构还是演进方向，答案是后者。

微软研究院最近有一项研究：

Optimizing Agentic Workflows using Meta-tools

它发现很多 Agent Workflow 会反复走以下路径：LLM → tool → LLM → tool → LLM → tool。但这些 tool-call pattern 实际上稳定重复，因此可以做如下收敛：Agent Trace → 发现高频 tool sequence → 自动封装成 Meta-tool → Agent 一次调用。

这样 LLM calls 下降，latency 下降，failure 下降，success rate 上升：

LLM calls ↓
latency ↓
failure ↓
success rate ↑

实验中 LLM calls 最多减少 11.9%，task success 提升最多 4.2 percentage points。(Microsoft)

这指向未来 Workflow 的一个演进方向：Workflow 不一定由人设计，也可能从 Agent execution traces 中编译出来。

从 trace 到确定性流程

过去是：Human designs workflow 未来可能是：Agent runs → Execution traces → Pattern mining → Stable subgraph → Compile into deterministic tool/workflow。

收敛路径如下：Agent → exploration → discovery → stable pattern → deterministic execution。最终系统变成：

Agent负责探索，Workflow负责固化。

论文证明的是 tool sequence 可以被打包成 meta-tool，业务流程可以被自动固化则是本文的架构推论，强度低于前者。

54. 三种“状态”必须分开

Agent-first 领域里有一条主张需要在这里澄清边界：Dynamic Plan 必须持久化。这句话对长时间运行的 Agent 是成立的，一个跑几小时的 Research Task，确实需要一个可检查、可恢复的工作计划。但金融架构必须把三种完全不同的状态分开，它们的所有者、变更权限和生命周期都不一样，混成一个就会直接导致 Agent 接管流程。

状态	含义	所有者	能否被改写
Business Workflow State	这个 case 在业务流程的哪一步	Workflow Runtime	只能按 BPMN 转移
Agent Task State	这个 Agent Task 在运行中、等工具、等人工还是已完成	Agent Runtime（对外可见）	受 Task Contract 与 Runtime 规则约束
Agent Working Plan	Agent 为了完成这个 Task 自己排的工作顺序	Agent Runtime（内部）	可在 Task 内自由调整，甚至推倒重来

Business Workflow State	Agent Task State	Agent Working Plan
BPMN: Compliance Review = RUNNING	Agent: RUNNING → WAITING_HUMAN	Agent: 1. Search policy = done 2. Search cases = done 3. Analyze evidence = running 4. Draft finding = pending

三者是包含关系：一个 Business Workflow State 之下有一个 Agent Task State，一个 Agent Task State 之下有一个 Working Plan，层次不同，权威源也不同。

分清楚之后，两个经常被混淆的判断就很清楚了：

Business Workflow State 只能由 Workflow Runtime 依据 BPMN 转移，任何第三方，包括 Agent，都不能直接改写；
Agent Working Plan 由 Agent Runtime 自己维护，它是否持久化、持久化到什么粒度、保留多久，由 Agent Runtime 决定，它不进流程引擎，也不参与审批与责任归属。

因此，不要把 Agent 的 Working Plan 提升为企业业务流程的 source of truth。反过来，如果一个平台需要回答整体业务卡在哪一步，它应该去查 Workflow Runtime，而不是解析某个 Agent 的 plan。这两件事被混起来，是 Agent 接管流程这类方案在落地时最常见的失控方式。

55. 不会被模型迭代绑死

比如未来可能经历以下模型更替：Claude → GPT → Gemini → DeepSeek → Qwen。 BPMN 完全不用变。Agent Runtime 可以通过一层 model abstraction 来变化：Agent Runtime → model abstraction。甚至 Runtime 选型本身也会换代：

2026: → LangGraph
2027: → Microsoft Agent Framework
2028: → internal runtime

业务流程仍然停留在：BPMN v7 金融企业在选型时通常会看重这一点。

56. 最终定义

BPMN 是企业业务流程的“可执行约束合同”——它约束流程怎么走，但不包含全部业务语义；DMN 是业务规则合同；Authorization / IAM 决定主体资格；Agent Policy 决定 Agent 的能力边界；Workflow Runtime 负责状态与生命周期；Agent 是完成复杂任务的智能执行者。

任何 Agent 驱动的业务动作，在产生业务状态变化或外部副作用之前，都必须经过确定性的 schema / business validation 与 authorization；是否需要 Human Approval，由 BPMN 与 Policy 按风险等级决定。

“可执行约束合同”这个限定不能丢。企业里用来描述业务的东西不止一件：Ontology 描述业务对象与关系，Business Data Model 描述数据的结构与版本，DMN 描述条件判断，Policy 描述许可，而 BPMN 只描述流程走向与责任。把 BPMN 当成包含全部业务逻辑的地方，是传统流程平台常见的过度承诺，它会把越来越多的判断塞进网关和条件分支，最后没有人敢改流程，也没有人说得清某条规则的来源。

换句话说，Workflow Engine 的长期价值不是流程图，而是对执行状态、等待、权限边界、事务副作用和恢复能力拥有执行权。流程图只是执行权的静态投影，Runtime 才是执行权本身。对金融而言，结论可以再收敛一句：金融不是拒绝 Dynamic Workflow，而是把 Dynamic Workflow 限制在 Deterministic Business Process 的边界之内。

执行路径形态即第 25 节主图的收束：Business Architect → BPMN / DMN → Workflow Runtime → Human / System / Agent Task → Agent Runtime → Structured Result → Policy / Validation → Human Approval / Auto Execute → BPMN State。

这套架构比彻底 Agent 化 Workflow 更适合金融，也比给 BPMN 加一个 LLM Node 更实用。它的处理方式不是推翻传统 Workflow，而是把边界划清楚：业务流程仍然确定，复杂任务开始智能化，业务状态仍然由确定性 Runtime 控制。这也是真正落地时应该坚持的主线。

最后再说一次核心命题

如果这篇文章只能留下一句话：

金融服务不应该在 BPMN 和 Agent 之间二选一。

BPMN/DMN 负责确定性的业务流程、业务规则和责任边界；Agent 负责流程内部那些难以规则化的认知任务；Workflow Runtime 负责业务状态和生命周期；Policy/IAM 负责 Agent 的权限；Agent 的输出必须以受约束的 Task Contract 返回，并经过确定性验证、以及按风险需要的人工批准，才能产生业务副作用。

这个判断与当前几个比较成熟的方向是一致的：

Camunda 官方已经把 agentic orchestration 定义成 deterministic + dynamic 并存，AI agent 负责流程中非确定性的部分；
AWS 的 Step Functions 可以直接调用 AgentCore Harness，把 Agent 当成 Workflow 中的一等步骤；(Amazon Web Services, Inc.)
Camunda 8.10 把 Agent 建模为流程里的一等执行对象，并能把已部署流程经由 Processes MCP Server 暴露给 Agent 调用；(Camunda 8 Docs)(Camunda 8 Docs)
Microsoft 的 Workflow 是 graph + executors + edges + state + runtime，同时提供 Durable Extension，而不是取消 workflow；
Temporal 把 Agent Loop 放进 durable workflow，并把 nondeterministic I/O 全部收进 Activity；
OpenAI 把 Agent Harness / Runtime 单独产品化，恰恰反证了 Agent Runtime 与 Business Workflow Runtime 必须分开；
Palantir 把企业语义与动作层独立出来，Snowflake 把 data-native agent runtime 独立出来，指向的是同一件事。

它比“彻底 Agent 化 Workflow”更适合金融，也比“给 BPMN 加一个 LLM Node”更实用。

57. 延伸阅读

学术和架构方面，可以参考：

Agent Workflow Survey (arXiv)
Architectural Implications of Agentic AI Workflows (arXiv)
Production-grade Agentic AI Workflows (arXiv)
Microsoft Agent Workflow Optimization / Meta-tools (Microsoft)
Agentic AI in Finance Survey (arXiv)
AI Agents in Financial Markets (arXiv)
Governing Agentic AI in FinTech (arXiv)

厂商架构方面，可以参考：

Anthropic Multi-Agent Research (Anthropic)
OpenAI Agents SDK / Responses API (OpenAI)
OpenAI Agents SDK 2026 Harness/Sandbox (OpenAI)
Microsoft Agent Framework Workflows (Microsoft Learn)
Microsoft Durable Agents (Microsoft Learn)
Google Agentic Enterprise (Google Cloud)
Snowflake Cortex Agents (Snowflake Documentation)
Palantir Ontology Architecture (Palantir)
Palantir Ontology MCP (Palantir)
Camunda Agentic Orchestration (Camunda 8 Docs)
OpenAI Agents API (OpenAI)

金融服务方面，可以参考：

Stripe production compliance agents (Amazon Web Services, Inc.)
AWS Financial Services AgentCore (Amazon Web Services, Inc.)
Snowflake Agentic AI in Financial Services (Snowflake)
Bank of England 2026 Financial Stability Report (Bank of England)
FSB AI governance practices (Financial Stability Board)
FINMA AI survey (finma.ch)

其中 FSB 的 2026 AI governance consultation、BoE 的 Financial Stability Report、Palantir Ontology、Snowflake Cortex Agents、Microsoft Durable Agent Framework、Anthropic Harness 这几条线放在一起看，基本就能构成一套比较完整的 2026 金融 Agent 平台参考架构。

流畅阅读（FluentRead）的文档翻译是怎么实现的

Tue, 08 Sep 2026 08:00:00 GMT

翻译一段话很容易，翻译一份 PDF 很难。

难不在调模型，而在翻完之后文件还是不是那个文件：Markdown 的标题层级还在不在，字幕的时间轴对不对得上，Word 的页眉页脚有没有被当成正文一起翻掉，PDF 的译文能不能落在原文那个位置上。

流畅阅读（FluentRead）是个浏览器翻译扩展，它的文档翻译模块用大约 102KB、7 个文件，覆盖了 13 种扩展名、11 种格式。读完这一块代码，最值得记下来的不是它支持了多少格式，而是它把这件事收敛成了一个极其干净的模型。

1. 这个模块长什么样

FluentRead 是按功能切片的，src/features/ 下面有 19 个 feature：划词翻译、全文翻译、图片翻译、视频字幕、术语表、写作助手…… document-translation 是其中之一 2。

它内部严格分三层，边界写在每个文件的头部注释里：

层	文件	职责	明确不做
core	`document.ts` (28KB)	纯领域模型、文本格式解析、无损回填	不读 File、不碰二进制、不发请求
core	`preview.ts` (11KB)	生成安全的预览 HTML	不操作真实 DOM
services	`binary.ts` (32KB)	PDF/ePub/DOCX 解析与导出	不调翻译服务
services	`translation.ts` (10KB)	批量翻译编排	不解析文件、不绑 provider
ui	`pdfPreview.ts` (14KB)	Canvas 光栅化	不决定片段与文件结构
ui	`presentation.ts` (5.5KB)	纯展示派生规则	不建 DOM、不解析
—	`public.ts` (1.3KB)	汇总公共 API	不暴露内部私有函数

值得注意的是 public.ts 的注释写得很直白：调用方应当通过公共契约注入翻译器和 PDF rasterizer，不要绕过 services 层直接耦合 JSZip、pdf-lib 或 pdfjs。这种”防君子也防小人”的边界声明，在一个只有 7 个文件的模块里算得上克制。

提醒一句：如果你之前 clone 过 FluentRead，注意本地那份可能是 fork（dalian-ai/FluentRead）的旧版 0.0.28 17，那时还没有 src/ 目录（是 WXT 的 entrypoints/ 结构 15），跟上游 main 已经不是一个代码库了。

2. 转轴：两条流，而不是一个数组

整个设计的支点，是 core/document.ts 里的 ParsedDocument：

export interface ParsedDocument {
  parts: readonly DocumentPart[]; // 原文骨架
  segments: readonly DocumentSegment[]; // 待翻译片段
  // ...
}

type DocumentPart = LiteralPart | SegmentPart;

interface LiteralPart {
  kind: "literal";
  value: string; // 原样输出
}

interface SegmentPart {
  kind: "segment";
  segmentIndex: number; // 指向 segments[]
  source: string;
  prefix: string; // 前导空白
  suffix: string; // 尾随空白
}

parts 是原文的完整骨架，按出现顺序排列；literal 承载一切不该翻译的东西——HTML 标签、字幕时间戳、ASS 的 Dialogue: 前缀、Markdown 围栏里的代码、行尾的换行符。segment 只是一个占位符，真正的文本在 segments[] 里。

回填时遍历 parts：

if (part.kind === "literal") {
  output.push(part.value);
  continue;
}
const translation = translations[part.segmentIndex] ?? part.source;

就这么简单。“保留原格式”不是一个需要为每种格式单独实现的功能，而是这个数据结构的自然结果。 格式之间的差异，被压缩成了”怎么切”这一件事。

翻译结果按 segmentIndex 落位，所以整条链路对”翻译服务”是无知的——它只看到一个 string[]。

3. 切分：11 种格式，各自的讲究

格式	怎么切	为什么这么切
TXT	按行	—
Markdown	按行，但代码围栏整体跳过；行内代码、图片、链接、裸 URL 保护为 literal	让受保护的语法保持原位不被拆散
HTML	手写 tokenizer，标签整体保护	见下
SRT / VTT	整条 cue 作为一个翻译单元	时间戳不送去翻译，模型才能保留 `<i>` 这类行内标签
ASS	数到第 9 个逗号才是对白正文	ASS 的 Dialogue 行是逗号分隔的定长字段
LRC	时间标签存为 `bilingualPrefix`	双语模式下第二行重复时间轴，产物仍是可播放的 LRC
JSON	递归只取字符串叶节点，记下 JSON path	键名、数字、布尔、嵌套结构都不动

几个值得单独说的：

HTML 的 tokenizer 是手写的。 没用 DOMParser，因为这里要的是”字符串级切分”而不是 DOM 树。findNextHtmlToken() 里有个细节：扫描标签时会跟踪引号状态，href="a > b" 里的 > 不会被误判成标签结束。head/script/style/pre/code/textarea 六个标签被整体保护——翻译 <script> 里的内容显然是灾难。

Markdown 有个 bilingualGroup。 一行文字里如果夹了行内代码或链接，切分后会变成多个 part。双语模式下如果各自插入译文，一行引用会被拆得七零八落。所以给每个 part 打上行号 bilingualGroup，渲染时按源行重新聚合，输出一条完整的双语行。

JSON 走的是完全不同的路径。 它不产生 parts，而是产生 jsonEntries（path + segmentIndex），回填时在深拷贝上 setAtPath，原始对象始终不变。双语模式下塞进同一个字符串：

`${entry.prefix}${original.trim()}\n${translation}${entry.suffix}`;

字幕的”整条 cue 作为单元”是个有取舍的决定。 好处是模型能看到完整上下文、能保留行内标签；代价是一段长对白无法再切细，会占满一批的字符预算。

4. 二进制三件套

PDF、ePub、DOCX 交给 services/binary.ts，产出统一塞进 ParsedDocument.binary（一个可辨识联合）。

4.1 PDF：从字符原子重建段落

pdf.js 12 的 getTextContent() 给出的是一堆字符原子（每个字或片段带自己的坐标变换矩阵），不是文本行。FluentRead 用三级几何聚类把它还原成段落：

atom → line：按 y 坐标排序，同行的判定是 |Δy| ≤ max(2, 行高×0.42, 原子高×0.42)。同时丢掉旋转角 > 0.12 弧度的文本（竖排/斜排直接放弃）。合成行时还会按间距补空格——但如果前一个原子以连字符结尾、下一个以小写字母开头，就不补空格直接拼接，处理英文换行断词：

if (/[-‐‑]$/u.test(value) && /^[a-z]/u.test(line.text))
  return `${value.slice(0, -1)}${line.text}`;

line → block：这是最费笔墨的一段。判定两块是否属于同一段落，综合了间距、水平重叠率、左边缘对齐、字号比、以及”上一行以句号结尾且当前行明显缩进”（新段落）。标题行（高度 ≥ 正文行高中位数 × 1.32）不参与合并。
每个 block 记下 x/y/宽/高/字号/行高中位数/行数/字体/字重/对齐方式——这套坐标就是后面重绘 PDF 的唯一依据。

4.2 ePub：zip + OPF spine

JSZip 14 打开 → 校验 mimetype 必须是 application/epub+zip → 读 META-INF/container.xml 拿 OPF 路径 → 解析 OPF 的 manifest（id → path）与 spine（itemref 顺序）→ 按 spine 顺序逐章读取，每章当作 HTML 丢给 parseDocument()。

有 fallback：如果 spine 里找不到 XHTML，就按 manifest 顺序兜底。章节标题从 <title> 里取，取不到用”第 N 章”。

4.3 DOCX：按 `<w:p>` 切段

const DOCX_PARAGRAPH_PATTERN = /<w:p\b[^>]*>[\s\S]*?<\/w:p>/gu;

扫描 word/(document|header\d+|footer\d+|footnotes|endnotes).xml，按段落切。每段还会识别角色：

if (/header/iu.test(path)) return "header";
if (/(?:footnotes|endnotes)/iu.test(path)) return "note";
const style = paragraph.match(/<w:pStyle\b[^>]*\bw:val="([^"]+)"/iu)?.[1] || "";
if (/title/iu.test(style)) return "title";
if (/heading|标题/iu.test(style)) return "heading";
if (/<w:numPr\b/iu.test(paragraph)) return "list-item";
return "paragraph";

页眉页脚、脚注尾注被单独分区，UI 上可以分开校对——这是很多翻译工具会偷懒的地方（直接把页眉当正文翻一遍）。

5. PDF 是最难的那个：不是替换文字，是重画一页

文本类格式可以”把译文塞回原位”，PDF 不行——它里面通常没有可以按 offset 替换的文本对象。FluentRead 的解法很硬：把整页光栅化，擦掉原文，按原坐标重新画一遍译文（实现见 ui/pdfPreview.ts）。

四步：

① 光栅化原页。 用 pdf.js 渲染到 canvas，缩放取 clamp(1.45, 1440/页宽, 2.4)。

② 采样取色。 这一步是全篇最有意思的地方。要在别人的版式上写字，得先知道背景是什么色、原文是什么色：

背景色：沿文字块的四条边各采样 8×2 个点，取中位数。用中位数而不是均值，是为了让边缘偶尔压到的插图/分隔线不至于带偏结果
前景色：在块内按步长采样（总样本控制在 ~3200 个），挑出与背景色欧氏距离 ≥ 48 的像素，按距离排序取最强的 22%，再取中位数

这套”中位数 + 距离阈值 + 取最强分位”的组合，效果就是自动还原原文墨色——深色背景的 PDF 也不会糊成一团黑。

③ 擦除原文块。 用背景色 fillRect 把文字块盖掉（外扩一点 padding）。注释里写明了为什么要先擦完所有块再统一绘制：

// 步骤 2：先统一擦除全部原文字块，避免重叠块把已绘制的译文再次遮住。

④ 按坐标写译文。 clip() 裁到原块矩形内再 fillText，这样多栏排版、图文混排都不会串位。字号自适应是个收缩循环：

while (fontSize >= 3.5) {
  context.font = `${block.fontWeight} ${fontSize}px ${family}`;
  lines = wrapCanvasText(context, translation, maxWidth);
  if (lines.length * lineHeight <= maxHeight * 1.02) break;
  fontSize -= Math.max(0.35, fontSize * 0.045); // 每次缩 4.5%
}

中文字体按原块 fontFamily 里有没有 serif 切两套（Noto Serif CJK SC / Noto Sans CJK SC）。

最后是导出：pdf-lib 13 新建 PDF，双语模式下一页放两幅图——左边 embedPage 原页、右边 embedPng 译页，中间留 clamp(8, 页宽×2.5%, 24) 的间隙。

代价要说清楚：产出的 PDF 是位图，文字不可选中、不可搜索、放大到一定程度会糊。这是”PDF 里没有可编辑文本”这个前提决定的，不是实现偷懒。另外扫描版 PDF（无文本层）会直接报错，明确不做 OCR。

6. 翻译编排：只认接口，不认服务商

services/translation.ts 定义了 DocumentTranslationGateway：

export interface DocumentTranslationGateway {
    getGlossaryOptions?(): {...};
    waitUntilReady(): PromiseLike<unknown> | unknown;
    getDefaultService(): string;
    supportsBatch(service: string): boolean;
    translateText(source, context, options): Promise<string>;
    translateTextBatch(sources, context, options): Promise<string[]>;
}

整个目录里没有任何一处 import 具体的翻译 provider。 翻译服务、术语表、用户设置全由上层注入。好处不只是可测试——FluentRead 有十几个翻译服务（划词、全文、字幕都在用），文档翻译只要注入同一个客户端就能全部复用。

调度上的几个决定：

分批：每批 ≤ 16 段且 ≤ 3500 字符，两个上限取先到
无批量能力的服务：起 Math.min(3, pending.length) 个 worker 抢同一个 nextIndex 游标，而不是 Promise.all 一把梭
语言对冻结：任务开始时快照 sourceLanguage/targetLanguage。注释写得很明确——“不能被设置页同步更新或用户中途改选污染后续批次”。翻到第 80 段时用户改了目标语言，前 79 段不会变成两种语言的混合体
上下文注入：取前 24 段拼成 pageContext 一起发给模型，让术语在全篇保持一致。这比”每段独立翻译”的质量高得多
结果校验：返回条数不符或有空串直接抛错，不静默降级

失败处理有个细节：Promise.all 首个 worker 失败就 reject，但其余在途请求还会稍后结束。所以用一个 stopped 标志位——失败后不再上报过期进度、也不再认领新片段，避免”已经报错了进度条还在涨”。

7. 「可续读」：这次重构真正改了什么

9 月 5 日的提交 feat(document): redesign translation as a resumable reading workspace 9 把文档翻译从”一次性动作”改成了”可长期维护的阅读工作区”。代码里对应两处，都很小但很关键。

其一，initialTranslations —— 空白驱动。

segments.forEach(({ id }) => {
  translations[id] = options.initialTranslations?.[id] || "";
});
const pending = segments.filter(({ id }) => !translations[id].trim());

已有译文直接落位（包括用户手工校订过的），pending 只装空白的。你在校订区改过的段落，重跑时不会被覆盖。 这让”翻到一半关掉，明天接着翻”和”只重翻我没改过的那几段”都成立。

其二，createDocumentFileLoadGuard() —— 代次而非 abort。

PDF/ePub 的解析是 async 循环，没有真正干净的中止点。与其假装能取消，不如用代次计数器：

let generation = 0;
return {
  begin() {
    const requestGeneration = ++generation;
    return { isCurrent: () => requestGeneration === generation };
  },
  invalidate() {
    generation += 1;
  },
};

新文件打开或页面重置时代次 +1，旧解析仍可自然跑完（不浪费、不泄漏），但 isCurrent() 返回 false，不允许把状态写进新文档。这是个很实用的模式：凡是你无法真正中止的异步流程，都可以用”所有权代次”代替取消。

另外 8 月底还有两个提交值得一提：0652882 10 审计重构回归并清理死代码，bf32cef 11 给源文件补了职责注释——所以现在每个文件头都有那段”文件职责 / 主要内容 / 模块边界”，读起来省很多事。

8. 回填与导出：每种格式的双语策略

同一个 renderDocument(document, translations, mode) 入口，mode 是 bilingual 或 translated，各格式的表现不同：

格式	双语模式	纯译模式
HTML	原文 + `<br>` + `<span data-fluent-read-document-translation>` 译文	直接替换（escape 后）
Markdown	原文行 + 下一行 `> 译文`（引用块）	替换
ASS	原文 + `\N` + 译文（ASS 的换行码）	替换
JSON	同一字符串内 `原文\n译文`	替换
ePub	逐章重新渲染写回 zip	同
DOCX	原段后追加一个粉色译文段落（`#E83B6B`）	原地替换 `<w:t>`
PDF	左右并排两页	单页译版

DOCX 的双语策略特意选了”追加段落”而不是”段内追加文字”——这样原文段落的所有格式属性（w:pPr、编号、样式）都不用碰，代价是多一个段落。

ePub 导出有个容易踩的规范细节：mimetype 必须用 STORE（不压缩）且是 zip 的第一个条目 16，否则很多阅读器不认：

zip.file("mimetype", "application/epub+zip", { compression: "STORE" });

9. 安全与限额

预览隔离（core/preview.ts）：生成的 HTML 带 CSP default-src 'none'; img-src data: blob:; style-src 'unsafe-inline'; base-uri 'none'; form-action 'none'，并且 stripActiveHtml() 额外剥掉 script/iframe/object/embed/form、on* 事件属性、meta refresh。被翻译的网页不会在扩展里执行任何东西
zip bomb 防护：≤ 4000 条目、单项 ≤ 24MB、解压后总计 ≤ 96MB，解析前后各校验一次
PDF 签名校验：开头 5 字节必须是 %PDF-，不然报”文件可能已损坏或扩展名不正确”
10MB 上限：DOCUMENT_MAX_BYTES = 10 * 1024 * 1024 定义在 core/document.ts，但这个目录内没有调用点，实际校验在上层 UI

10. 能抄走的四个设计

不是抄代码，是抄判断。

一、把”不可变结构”和”可变内容”分成两条流。 一旦这么分，“保留原格式”就不用为每种格式单独实现了。任何”处理完还得还原”的任务——代码格式化后保留注释、模板渲染后保留手写修改、i18n 提取后回填——都是同一个形状。

二、feature 只依赖注入的接口，不依赖具体实现。 文档翻译模块不知道自己用的是 Google 还是 DeepL，只知道有个 translateTextBatch。这让 11 种格式的复杂逻辑可以脱离网络、脱离扩展环境单测。

三、无法真正中止的操作，用所有权代次代替取消。 强行 abort 一个 async 循环只会留下半初始化状态。让旧任务自然跑完但不许它提交，是更省心的做法。

四、在别人的版式上写字，先采样再擦除。 “取中位数当背景、取最强分位当前景、先擦完再统一画”这三步，是”往不可编辑的画布上写字”这类问题的通用解法。

最后说回开头那句话。翻译一段话容易，翻译一份 PDF 难——难在你要为每种格式回答同一个问题：哪些东西不能动。

FluentRead 的回答是：先把不能动的全挑出来放进 literal，剩下的才叫”内容”。

参考

大模型结果如何测试和验证：Anthropic 与 OpenAI 的方法论

Tue, 08 Sep 2026 02:02:03 GMT

最近被反复问到一个问题：

大模型的结果怎么测？怎么保证 100% 准确？

我去翻了 Anthropic 和 OpenAI 的一手工程文档。先说结论（措辞上收敛一点：以下是我查到的公开材料范围内的归纳，不是全称判断）：

在我查到的这些公开材料里，没有一家把 100% accuracy 当作现实可行的工程目标；OpenAI 的相关工作甚至专门讨论了为什么绝对准确不是合理目标。

他们真正在做的事，是另一套东西：把不可控的生成，拆成可判定的断言 + 可归因的失败 + 可回归的门禁。

阅读指引：本文混合了三种陈述，下文用括号标注——【原文】= 一手文档明确说的；【归纳】= 我对多篇文档的归纳；【推论】= 可直接落地的工程推论。

1. 先破题：为什么 100% 是个错误问题

OpenAI 的论文《Why Language Models Hallucinate》（PDF）里有三句判断，基本终结了这个问题【原文】：

常见主张	论文的发现
提高准确率就能消除幻觉，100% 准确的模型永远不会幻觉	准确率永远到不了 100%——有些现实问题本质上不可答（信息缺失、歧义、需要澄清）
幻觉不可避免	不是。模型在不确定时可以选择沉默
消除幻觉需要很高智能，只有大模型做得到	相反，小模型更容易认知自身局限（校准所需算力远低于追求绝对准确）
幻觉是现代模型里的某种神秘故障	不是。统计机制与评测激励都已经搞清楚了

1.1 幻觉有两个来源，第二个才是主因

来源一：预训练的统计不可约性【原文】。

预训练是在海量文本上做”预测下一个词”。和传统机器学习不同，每条陈述都没有”真/假”标签——模型只看到流畅语言的正例，必须去近似整体分布。

论文把这个归约成一个叫 IIV（Is-It-Valid，这条陈述有效吗） 的问题：当你手里只有正例、从来没见过被标记为”无效”的样本时，区分有效与无效陈述本质上是无监督的，难度高得多。

为什么模型很少拼错单词、很少括号不匹配，却会编造生日？论文的类比很漂亮：

给几百万张猫狗照片打上”猫/狗”标签，算法能可靠分类——因为存在可学习的模式
改成按宠物的生日给照片打标签——生日本质上是随机的，无论算法多先进，这个任务必然出错

拼写在语料里有极其稳定的模式，规模上去错误就消失；而”某人的生日”这种任意的、低频的事实没有模式可循，于是产生幻觉。

论文还给了一个可量化的下界：

预训练之后的幻觉率，至少等于训练事实中只出现过一次的比例。例如，若 20% 的生日事实在预训练数据中只出现过一次，那么基础模型在这类事实上至少会幻觉 20%。

这一条很硬：有些错误不是训练不够好，是信息本身就不在模型里。

来源二（更关键）：后训练阶段被评测机制奖励出来的【原文】。

1.2 一组让人不舒服的数据

论文给了一组真实数据（SimpleQA，出自 GPT-5 System Card）【原文】：

指标	gpt-5-thinking-mini	OpenAI o4-mini
弃权率（不给具体答案）	52%	1%
准确率（答对，越高越好）	22%	24%
错误率（答错，越低越好）	26%	75%

（三行相加都是 100%：准确 + 错误 + 弃权。）

单看准确率，老模型 o4-mini 反而更高。但它的错误率是前者的近 3 倍——因为它几乎从不弃权（1%），什么都敢猜。

论文的类比很直白：这就像选择题考试，空着必然 0 分，蒙一个还有 1/4 概率对。

当成千上万个 benchmark 都用 0-1 打分，模型就会学会”永远别承认不知道”。模型永远处在”考试模式”里。

论文的用词是 “an epidemic of penalizing uncertainty”（一场惩罚不确定性的流行病）。他们特别强调：

只在旁边加几个新的”幻觉评测”是不够的。主流评测本身必须改。

因为只要主榜单还在奖励幸运的猜测，少数几个幻觉评测的影响力根本压不过去。

1.3 解法：改评分规则，不是改模型

具体做法是在每道题的 prompt 里显式写明阈值【原文】：

答对 +1 分；回答”我不知道”得 0 分；答错扣 t/(1-t) 分。请只在你确信答对概率大于 t 时才作答。

其中 t 是置信度阈值。有了这条规则，模型就会把自己的置信度和 t 比较——低于阈值时，最理性的策略就是弃权。

这个思路并不新：标准化考试早就用”答错倒扣分”来遏制瞎猜。新的是 OpenAI 把它主张为所有主流 benchmark 都应该改的计分方式（MMLU、SWE-bench 等）。

1.4 对做应用的人，三条直接含义【推论】

如果你自己的评估体系只统计”准确率”，你就在亲手训练你的系统去瞎猜。
给”我不知道”一条合法出路，并且在指标上不惩罚它。 弃权是特性，不是缺陷。OpenAI 甚至把”谦逊（humility）“写进了 Model Spec——宁可表明不确定或请求澄清，也不要给出可能错误的自信信息。
校准比准确便宜。 让模型知道自己不知道，所需的算力远低于让它答对。小模型在这件事上反而有优势——论文的例子是：面对毛利语问题，完全不懂毛利语的小模型可以直接说”我不知道”；而懂一点毛利语的模型反而需要费力评估自己的置信度。

2. 全文的总模型：Eval 不是出题，而是在证明一个 Claim

这是全文最重要的骨架【归纳】。后面所有章节（判定、题目、环境、评分器、指标、生产）都是这个链条上的一个环节：

Claim → Task → Elicitation/Harness → Environment → Observation → Grader → Metric → Decision → Feedback

展开成一个具体例子——“这个 Agent 能可靠地处理退款请求”：

Claim:
"这个 Agent 能可靠地处理退款请求"

↓ 拆成

Task:
用户要求取消一笔符合条件的订单

↓ Elicitation / Harness（诱发与脚手架，见 §5）:
prompt、工具集、context 管理、retry、budget——决定能力是否被诱发出来

↓ Environment（环境）:
账户、订单、退款 API、权限、policy

↓ 行为:
Agent 调用工具、查询订单、执行退款

↓ Observation / Outcome:
订单状态 = refunded
退款金额正确
没有越权
没有修改其他订单

↓ Grader:
状态检查 + 金额检查 + 权限检查 + Policy 检查

↓ Metric:
pass@1 / pass^k / 错误类型 / 成本 / 延迟

↓ Decision:
是否上线？灰度多少？转人工阈值？

↓ Feedback:
生产失败 → 新 Task → 回归套件

理解了这个，就理解了全文的核心论点：

Eval 不是”给模型出题”，而是构造一个能够支持 / 反驳某个产品或模型 Claim 的实验。

于是”AI 系统为什么不能靠一个准确率证明自己可靠”，就有了答案：因为链条上有 6 个不同层次的问题，准确率只覆盖了其中一段【归纳】：

A. Construct / Claim——你到底想证明什么？（§2）
B. Task Validity——题目是不是一个有效代理？（§3、§4）
C. Execution / Elicitation——harness / environment / budget 是否改变了能力表现？（§5）
D. Measurement——observation / grader / metric 是否测到了你想测的东西？（§6、§7）
E. Generalization——结果能不能推广到目标生产分布？（§7、§9）
F. Operationalization——结果能不能进入发布、监控、回归和事故反馈？（§9）

前四层是测量与效度问题，后两层是外部效度与生命周期问题——不要把它们放在同一层比较。

后文导读： §3–§7 按这个顺序逐关展开；§8 把”模型”换成”系统”；§9 闭环到生产；§10 只保留大厂证据；§11 给最小可跑方案。

3. 第一关：这个东西能不能被判定？

第一判断仍然是：哪些输出能判对错，哪些不能【推论】。但”可判定 / 不可判定”二分太粗，拆成三种判定强度才够用【归纳】。注意：不是三类任务，而是三种判定强度——同一个任务里往往同时存在三部分（见 §10.3 的 Data Agent 案例）。

3.1 Deterministic / Observable（确定性判定，最好）

数据库里是否新增了一条记录？
文件是否存在？
测试是否通过？
金额是不是 100 元？
权限是否越权？

判定方式：确定性检查（SQL 查询、文件断言、测试套件、规则引擎）。这是 Anthropic 《Demystifying evals for AI agents》里 Transcript ≠ Outcome 区分的落点【原文】：

订机票 agent 在对话里说”您的航班已预订”——这只是 Transcript。只有当你去查后台 SQL，发现真的多了一条预订记录——那才叫 Outcome。

工程含义：先把 outcome 的可观测性建起来（能查库、能查状态、能查副作用），再谈 grader。 很多团队反过来做，grader 只能判文本，天然测不准。

判据用一句人话即可【推论】：

“是否可以把成功标准定义成一个可重复执行、与具体实现无关的判定规则？”

例如文件存在、金额 = 100、数据库状态 = refunded、测试通过、权限未越权——这才是 deterministic。

注意：“两个不同的人看了都觉得不错”只是 inter-rater agreement，不等于 deterministic grading——两个人可能只是共享偏见，并不代表存在稳定、可自动执行的判定规则。

3.2 Semantic / Model-assisted（语义判定，需要组合拳）

SQL 是否实现了相同语义？
回答是否完整？
方案是否满足约束？
摘要是否忠实？

这类不能字符串比较。OpenAI 内部 Data Agent 《Inside our in-house data agent》明确绕开了”朴素字符串匹配”的坑【原文】：生成的 SQL 语法不同但可能正确，结果集多几列但不实质影响答案——所以同时比对 SQL 与结果数据，把两个信号一起喂给 grader，产出分数 + 解释。

标准打法：

deterministic checks + LLM grader + human calibration

只比 SQL 字符串 → 漏判语义等价；只比结果集 → 放过”碰巧结果一样但逻辑错了”的查询。两个信号一起给 grader，是比”跑个 diff”高一档的做法。

3.3 Subjective / Human-calibrated（主观判定，以人为准）

哪个方案更好？
这个回答是否"有洞察"？
这个 UI 是否更自然？

这类通常不存在唯一、完全客观的 ground truth，只能进：

rubric + pairwise comparison + expert review + calibration + agreement measurement

但”主观”不等于”全不可判定”：很多主观任务内部仍有大量可判定部分——如代码 review 是否遗漏安全漏洞、是否违反规范、是否包含必需检查项；Anthropic 对 research agent 也是用 groundedness、coverage、source quality 等 grader 组合，而不是简单归为”完全没有 ground truth”【原文】。

Warp 的做法《How Warp builds self-improving agents on Claude》是个参照【原文】：领域可验证 → 先建 verification harness；领域不可验证 → 依赖 golden outputs 的确定性 eval，人类反馈只限领域专家（“don’t open the floodgates”）。

最高杠杆的动作不在下游加校验，而在上游把需求改成可判定的【推论】。以下全是产品决策：

原本的需求	改成可判定
“帮我分析一下数据”	回答必须落到某张表的某个指标，并给出取数口径
“写个方案”	方案必须包含 A/B/C 三项，缺一项算未完成
“回答用户问题”	答案必须给出可核对的来源，没有来源就说不知道
“帮我处理这个任务”	必须能说出完成后的世界状态是什么（多了一条记录？状态变成 X？）

判定不了的需求，再强的验证手段也救不回来。

4. 第二关：题目本身是否有效？

OpenAI 这条线最打动我的地方是：他们先审计 benchmark，而不是先吹分数【原文】。

背景见《Separating signal from noise in coding evaluations》：SWE-Bench Pro（731 题，从仓库变更历史程序化生成，要求通过新增测试且不破坏既有功能）在八个月内被前沿模型从 23.3% 推到 80.3%，然后 OpenAI 掉头审计了它自己推荐的 benchmark，结论是约 30% 的任务是坏的。

4.1 三段式质检流水线【原文】

阶段	做法	结果
1. 自动过滤器	审查指令、模型尝试、打分测试本身	标出 286 个潜在坏题
2. 人工监督的 agent 复审	Codex investigator agents 跑测试、读文件，区分”合理歧义”与”规格不足”，研究员做最终判定	认定 200 个（27.4%）
3. 人工标注	每个任务 5 名工程师独立评审，分歧与低置信上报	认定 249 个（34.1%）

值得注意：人类比 agent 更倾向判坏题（34.1% vs 27.4%）——agent 辅助审计能提速，但替代不了人类判断。

4.2 坏题的四种长相【原文】

类型	后果
测试过严（强制了 prompt 没说的细节）	功能正确的提交被判错 → 分数偏低
prompt 规格不足（隐藏测试要的东西没写）	做对了也过不了 → 分数偏低
测试覆盖不足	不完整修复也能过 → 分数虚高
prompt 误导（与测试矛盾）	分数失去意义

四种错误不会互相抵消——混在一起，那个数字基本无法解释。

4.3 【推论】Eval case 是软件资产，要有生命周期

不要只记住”30% 坏题”，要记住：Evaluation Dataset 本身就是 Software / Data Product。

Draft → Review → Validation → Active → Regression → Drifted → Retire

每个 case 至少带这些元数据：

task_id: refund_top5_001
version: v3
claim: "Agent 能正确查询退款率"
expected_outcome:
  {
    top_5_products: [...],
    refund_rate_definition: "refund_orders / paid_orders",
  }
reference_solution: golden.sql
grader: grader_v2
known_ambiguities: ["退款率口径需在 prompt 中显式声明"]
difficulty: medium
risk: high # 涉及资金
last_reviewed: 2026-08-20
owner: data-agent-team
status: active

自建 eval 的硬规则要分情况说【归纳】：对于可验证任务，应尽可能提供一个能通过全部 grader 的 reference solution，用来证明任务可解并验证 grader；对于开放式任务，则至少需要可操作的 success criteria / rubric。 Anthropic 建议每个 task 有 reference solution【原文】，但 conversational / research 类任务允许多个合理解法，不适合要求唯一 reference output。你的 Data Agent 例子属于前一种，所以保留 golden SQL 完全成立。

τ²-bench 的 v1.0.1 一次做了 75+ 项任务质量修复（移除错误预期动作、修掉不可能满足的约束），甚至触发榜单重评分——这就是”活资产”的常态。

5. 第三关：实验条件是否公平？Harness 是变量

《A shared playbook for trustworthy third party evaluations》提出了一个会被反复引用的概念：harness【原文】。

早期评测把模型当聊天机器人：问、答、判分。今天的模型用工具、跨多步保持信息、在工作流中行动。 性能不只取决于模型，还取决于任务发生的环境，以及促成其行动的设置。

一个保留状态、对失败自动重试的 harness，可能让同一个模型完成多步任务；而在简单 harness 里永远完不成。所以”模型 + harness”才是实际被测系统（Anthropic 2 同样明确说了这点）。

5.1 【归纳】把 Harness 理解成”实验条件”，把 Elicitation 单独拎出来

Model = treatment（处理）
Task = stimulus（刺激）
Elicitation/Harness = 诱发手段 + 实验装置
Environment = context（上下文）
Grader = measurement instrument（测量仪器）
Metric = statistic（统计量）

Harness 是”实验条件”，但 OpenAI 7 的核心词其实更进一步，叫 elicitation（诱发）【原文】：你有没有真正把系统的能力”诱发出来”？ 同一个模型，配不同的 context 管理、tool access、retry、budget，测出来的能力完全不同。OpenAI 甚至把 strongest credible elicitation 作为 capability claim 的组成部分。

所以链条里写成 Elicitation/Harness：harness 偏 infrastructure（容器、工具、隔离），elicitation 回答”如何让 agent 发挥它本来具备的能力”。只谈前者，实验条件就不完整。

这能解释：为什么不同 benchmark 分数不能直接比？为什么 prompt 变了但模型没变分数会变？为什么 tool availability 会改变排名？——因为实验条件变了。

OpenAI 要求评测报告必须写清两件事【原文】：这个评测想验证什么 claim；有什么证据表明结果有效。 三类 claim 对应不同 harness：能力激发（最强激发配置）/ 受控对比（任务、评分、预算全固定）/ 防护性能（针对攻击设计）。

对比时的诚实要求【推论】：任务、评分、预算、脚手架全部固定，否则你看到的差异很可能只是脚手架的差异。

5.2 Eval Manifest：让实验可复现

【推论】每个 eval 运行都应该有一份 manifest，随报告一起存：

model: claude-opus-4-5-2026xxx
prompt_version: refund-v7
harness_version: harbor-0.3 / codex-cli-xxx
tools: [schema_search, sql_execute]
max_steps: 20
max_tokens: 8000
temperature: 0.0
retry_policy: { max_retries: 2, backoff: exponential }
memory: { enabled: false }
network: disabled
dataset_version: refund-eval-v3
grader_version: grader_v2
budget: { cost_cap_usd: 5.00, time_cap_s: 300 }

5.3 Trial：点估计不够，要不确定性

Anthropic 引入 trial（同一 task 跑多次）的原因很朴素：一次成功可能是运气【原文】。但要再往下推一层【归纳】：

不要只报 pass@1 = 72%，要报 72% ± 不确定性（置信区间）。
A = 72%, B = 75% 不能直接说 B 更好——要问样本量、trial 方差、是否配对比较。Task 本身才是主要实验单位，而不是单次生成。
每次 trial 必须隔离（全新容器、不保留状态、默认无网络）。Harbor 把这做成了默认值（见 §11）；Anthropic §10.1 的事故则是反面教材——提示词说无网络，容器实际有出口。

5.4 一个统计陷阱：pass^k 的独立性假设

0.9^10 ≈ 35% 的直觉解释很好，但它隐含了 trial 之间近似独立【推论】。现实中常常不是：同一个 prompt、同一个缓存、同一个 failure mode、同一个坏掉的工具——失败是相关的。

如果 trial 不是独立样本，那么重复跑 100 次也不等于获得了 100 个独立证据。

这正是 trial isolation 不是形式主义的原因。

5.5 读评测报告的七问【归纳自 7】

它想证明哪一类 claim？2. harness 是什么，和部署环境像吗？3. 预算（步数/token/时间/成本）是多少？4. 评分器是什么，模型自己给自己打分吗？5. 有没有排查 reward hacking、contamination、broken problems？6. 拒答率是多少？7. 弃权怎么处理？——不报弃权率的准确率都是耍流氓。

五类效度威胁速查（7 原文）：Reward hacking / Refusals / Contamination / Broken problems / Sandbagging。注意最后一条已是实测事实：GPT-6 Astra 安全评估里专门做了 monitorability 与 controllability 调查，发现模型在对抗环境下能战略性低估而不被发现。

6. 第四关：评分器本身是否可信？

6.1 三类 Grader 各自的坑【原文自 2，含误用为归纳】

类型	优势	劣势
代码型（匹配/测试/静态分析/结果验证）	快、便宜、客观、可复现	对”有效变体”脆弱；主观任务无能为力
模型型（rubric/断言/成对比较/多裁判）	灵活，能处理开放输出	非确定性、更贵、必须与人工校准
人工型（专家/众包/抽样/A-B）	金标准	贵、慢

典型误用：用字符串匹配判”意思”；把模型 grader 当金标准；拿人工做日常回归。组合方式：加权 / 一票否决 / 混合。Anthropic 的实用建议：grader 聚焦产出而非路径，并考虑部分分——否则会重演”模型找到更优解却被判失败”（τ²-bench 订机票案例：Opus 4.5 发现政策漏洞、绕过去订得更好，eval 判失败）。

6.2 Meta-Eval：谁来评估评委？

这是全文最该强化的一点【归纳】。“模型 grader 必须人工校准”只说了一半，另一半是：怎么知道 grader 是好的？

System → Task → Grader → Grader 是否正确？ → Meta-Eval

做法很朴素：取 100 个样本，同时跑人工 gold label 与 LLM grader，对比 accuracy / precision-recall / false positive-negative / agreement。

但真正的风险不是”它不准”，而是它稳定地偏：

LLM grader 总是偏爱：更长的答案、更正式的表达、
某一种架构、某个模型家族、某种写作风格

于是出现一个比”grader 会错”深得多的结论：

Grader Reliability ≠ Grader Validity。Grader 可以很稳定地测错东西。

6.3 Reliability vs Validity：全文最大的理论缺口

“可信”其实是两个完全不同的问题【归纳】：

Reliability（信度）：同样的东西重复测，结果稳定吗？看 variance、置信区间、可重复性、评分者间一致性。
Validity（效度）：这个测试到底测到了你想测的东西吗？SWE 分数很稳定，但如果题目本身错了——Reliability 高，Validity 低。

                Valid
                 ↑
      好评测     │
                 │
Stable ──────────┼────────── 不稳定但有效
                 │
      稳定地测错 │
                 ↓
              Invalid

一句话：一个评测可以非常稳定地测错东西。 OpenAI 的 benchmark 审计、Anthropic 的 broken eval、harness 变量，全部是这句话的证据。

6.4 Eval quality 三件套：Validity / Reliability / Sensitivity

Reliability + Validity 还缺一块：Sensitivity / Resolution（分辨率）【归纳】——这个 Eval 对系统改进还有没有分辨率？§9 的 eval saturation 说的正是这个：

System A = 98%, System B = 99%   # 只看总分，提升 1%
核心困难任务：A 20%, B 60%        # 大量简单题把差异淹没了

最终定义：测得对不对（Validity）、测得稳不稳（Reliability）、能不能看出真正的改进（Sensitivity）。 这也把 capability / regression / saturation 统一起来：capability eval 要保 sensitivity（专挑能拉开差距的题），regression eval 要保 reliability（稳定的题才配当门禁）。

7. 第五关：一个数字不够描述可靠性

7.1 准确率不是充分统计量

至少要拆开【归纳】：

Correctness / Completeness / Consistency / Robustness /
Calibration / Safety / Cost / Latency / Recoverability

一个系统完全可能 Accuracy 95% 但 Consistency 70%、Calibration 很差、Cost 极高。也可能 Accuracy 98% 但关键交易仍不可上线——因为错误不是等价的。

系统	正常任务准确率	高风险任务错误率	弃权率	pass^5
A	98%	5%	1%	低
B	95%	0.5%	12%	高

哪个更可靠？数字本身回答不了。Metric 必须服从 Failure Cost，而不是反过来。 再往下推一层就是 expected loss【推论】：

Expected Loss = P(wrong)×Cost(wrong) + P(abstain)×Cost(abstain) + P(correct)×Cost(correct)

阈值谁定？业务定，不是算法定——因为”错一次”和”少答一次”哪个更贵，只有业务知道。

7.2 Selective Prediction：弃权只是一半

“给’我不知道’一条合法出路”很好，但完整形态是决策策略【归纳】：

Answer / Abstain / Ask clarification / Retrieve evidence /
Escalate human / Retry with another model / Use deterministic tool

用户问事实问题 → 模型置信度 → 高：直接回答 / 中：检索验证 /
低：不回答 / 高风险：转人工

可靠系统优化的是决策策略，而不只是回答本身。兜底路径必须存在：没有兜底，“允许弃权”只是一句空话。

7.3 pass@k vs pass^k：选错指标等于选错产品

指标	含义	适用
pass@k	k 次里至少成功 1 次	辅助工具（多试几次成一次就行）
pass^k	k 次全部成功（观测到的全成功比例）	客服、交易、数据管道（每次都必须对）

pass@1=90% 看着不错。但注意：0.9^10 ≈ 35% 不是 pass^k 的定义，而是如果每次 trial 独立且单次成功概率稳定为 90%，理论上的 all-success 概率【推论】。同一个系统，“单次成功率 90%“和”独立假设下连续 10 次都对 35%“是同一件事的两种说法。

还要补一句：pass^k 和真实生产连续成功率并不完全等价——真实生产任务的难度分布不是固定 p。看分布要分三层：per-task pass rate vs aggregate pass rate vs tail-task reliability（最难的那批任务决定下限）。实践折中：pass@1 做快速迭代，pass^k（k 取业务能容忍的连续失败代价）做发布门禁。评分规则同样是产品决策：弃权通道 + 兜底路径 + 业务定阈值。

8. 从”测试模型”到”测试系统”

8.1 复杂度递进与 transcript 优先级

Anthropic 把评估分成三档【原文】：单轮（看文本）→ 多轮（给工具+环境，看产物）→ Agent（跨回合改状态，看最终状态+过程）。Agent 最难因为错误会传播复合，且前沿模型会找到超出静态 eval 边界的解法。

语音场景同理（Realtime Eval Guide）：内容质量（理解、做对事）与音频质量（自然度、稳定性）是两个独立轴，单分数会掩盖问题；且必须分阶段打日志（speech start/stop → commit → response.create → audio deltas → done），当黑盒测永远定位不了根因。

8.2 Failure Taxonomy：Eval 的产物不是分数，是可行动的失败信息

failed / broken / wrong 指导不了工程。用二维结构代替互斥长清单【推论】：

维度一 Cause（谁的错）： Model / Agent policy / Tool / Environment / Harness / Grader / Task

维度二 Failure mode（错在哪）： Knowledge / Reasoning / Instruction / Tool use / Safety / Abstention / Recovery

Cause = Tool,        Mode = Argument error      # 参数错
Cause = Task,        Mode = Ambiguous spec      # 题目歧义
Cause = Grader,      Mode = False positive      # 评委误判
Cause = Model,       Mode = Reasoning error     # 推理错
Cause = Harness,     Mode = State pollution     # 状态串扰
Cause = Environment, Mode = Infra failure       # 环境坏
Cause = Agent policy, Mode = Abstention error   # 该弃权没弃

一维长清单（F1–F12）的问题是 F6/F7、F2/F3 互相覆盖，F10/F11 一个是 domain 一个是 behavior。二维结构直接回答归因最需要的两个问题：哪里坏的 × 怎么坏的。

Accuracy = 80% 没法指导下一步；但”工具参数错 8%、题目歧义 5%、策略理解错 4%、grader 误判 2%“马上能指导。

Eval 的终极产物不是分数，而是可行动的 failure information。

8.3 可归因：好 Eval 的输出格式

一个好的 Eval 至少输出【推论】：

Pass / Fail + Why + Where + Who/What caused it + Can it regress?

例如：

FAIL — 退款未创建
Root cause: tool-call #4 的 order_id 参数错误
Cause = Tool, Mode = Argument error
Stage: tool-call #4
Regression: yes（加入回归套件）
Suggested fix: tool schema / prompt / retry policy

8.4 Eval 驱动开发（EDD）

传统开发是 Bug → Fix → Test；AI 系统是【归纳】：

Failure → Eval → Fix → Regression

Anthropic 的 SDLC playbook 4 把它写成了纪律【原文】：修 bug 先写失败测试并提交，用 hook 阻止 agent 改测试，再让 agent 修。Eval 在 AI 系统里扮演传统 Unit Test + Integration Test + Production Monitoring 的混合角色——但它比 unit test 更宽，因为被测对象是非确定性的系统。

9. 从离线 Eval 到生产可靠性

9.1 Benchmark ≠ Production Eval

这两个概念必须分层【归纳】：

Benchmark → Capability Eval → Regression Eval → Production Monitoring → Incident Eval

层	回答的问题
Benchmark	这个能力大概怎么样（capability signal，如 SWE-bench）
Capability	能力边界在哪（专挑翻车的题，通过率 10–30% 也正常）
Regression	以前解决的问题坏了吗（已稳定的题，接近 100%，掉分即 bug）
Production Monitoring	我的系统今天还能不能工作（真实分布）
Incident	哪些 failure 该永久进入测试集（discovery signal）

Anthropic 的定义很清楚【原文】：能力 eval 是”进攻战”（要爬的山），回归 eval 是”保卫战”；当能力 eval 通过率做上去，它就”毕业”进入回归套件。关键纪律：冲能力指标时必须同时跑回归，否则为了爬山把营地烧了。

9.2 Swiss Cheese：每层解决什么未知

没有任何单层能拦住所有问题【原文自 2】。改成决策表【归纳】：

层	解决的未知	节奏
Regression	以前解决的坏了吗	发布前、CI
Capability	能力边界在哪	迭代期
Adversarial	没想到的失败是什么	周期性
Production Monitoring	真实世界怎么失败	持续
Human review	Grader 是否错了	每周抽样
Incident	哪些 failure 该永久入集	每次事故

flowchart LR
A["自动化 Eval<br/>（快速迭代、CI 门禁）"]
B["生产监控<br/>（分布漂移、真实失败）"]
C["A/B 测试<br/>（大流量验证显著变更）"]
D["用户反馈 + 抽样读 transcript<br/>（持续、每周）"]
E["系统性人工研究<br/>（校准 grader、主观金标准）"]
A --> B --> C --> D --> E

9.3 真正的 flywheel：生产失败是资产

完整回路【归纳】：

真实用户 → 失败 → Incident/Feedback → Failure Classification →
New Eval Case → Regression Suite → 系统修改 → Release →
Production → 再次发现未知失败 ↺

Anthropic 的 transcript、OpenAI 的 benchmark 审计、Data Agent 的 production canary、Warp 的 skill 改进、Realtime 的生产飞轮——看似分散，其实都在描述同一个闭环。

三条硬纪律【原文+推论】：

每个生产事故必须写成一条 eval（Anthropic playbook 原文）。复盘会产出清单里必须有一项”本次新增的 eval 描述”。
谁每周读 transcript：如果你找不到一个愿意每周花两小时读 transcript 的人，这套体系半年内一定烂掉。先解决这个人，再谈平台。
验证基础设施自己也要被验证：Anthropic 三起网络安全 eval 事故（详见 §10.1）的教训——提示词说无网络，容器实际有出口。事前验证隔离、实时监控日志、第三方审查，都要显式列进预算。

10. 大厂案例：统一框架下的证据

本节不再是主体，而是 §2–§9 的证据链。详略有调整：Astra 大幅压缩，工具产品介绍压缩（完整选型见 §11）。

10.1 Anthropic：能力边界的真实压力测试

《Investigating three real-world incidents in our cybersecurity evaluations》公开了自家事故【原文】。2025 年 2 月起用 Claude Sonnet 3.7 跑 Cybench（40 个 CTF），后加 CyberGym、ExploitBench，与 Irregular 等外部伙伴协作，开放式夺旗，多数环境不连互联网，跑在隔离 infra 上。

关键设计：为测能力故意摘掉防护——评估模型不带可用版本的分类器与监控，但保留安全训练。测的是”模型能力”而非”产品行为”；代价是一旦隔离出错，摘掉的那层就真没了。

三起事故根因相同：提示词说无网络，但与 Irregular 的误解导致容器实际有互联网出口，模型把真实系统当模拟靶场（共 6 次运行）：Opus 4.7 攻入与虚构目标同名的真实网站（识别为真后仍继续）；Mythos 5 真的注册并上传了恶意 PyPI 包（留存约 1 小时，被 15 个真实系统下载）；内部研究模型扫描约 9,000 个目标，后期自行判断为真并主动停止。三者连起来是一条情境意识梯度。

事后：7 月 23 日回溯 141,006 条运行记录、次日锁定；对接 METR 独立审查；公开轻度编辑的 transcript；联系受影响组织。改进项本质一句话：验证系统需要的防御纵深，不比被测系统少。

10.2 Anthropic：AI-Native SDLC 可抄的部分

《The AI-Native SDLC playbook》把 Plan/Design/Build/Test/Deploy/Maintain 重构成工件链（intent → spec → plan → diff+测试 → PR 发现 → 事件记录）【原文】。测试部分可直接抄：验证包装成单命令（make test，失败非零退出）；先写失败测试再修；CI 跑 20–50 个真实任务，通过率不下降才能合并；事故转 eval；会话结束用全新上下文的 Verifier subagent 只报告不修复；确定性 hook 做硬门禁（RELEASE_APPROVAL、deny .env/secrets、沙箱白名单）。

值得单拎：咨询性控制 vs 确定性控制【归纳】。CLAUDE.md、Skills 是咨询性的（模型可不听）；Hooks、分支保护、受管设置是确定性的（不依赖自觉）。只有后者能当门禁。

10.3 OpenAI Data Agent：一个基于公开做法的合成 Eval Case

《Inside our in-house data agent》是”自家产品怎么保证对”的实操文。本节把它拆到底，作为 §2–§9 的完整纵贯案例。

事实边界：公开事实 = golden SQL、同时比对 SQL 与结果集、grader 出分 + 解释、权限透传、工具收敛（Less is More）、Meaning Lives in Code；**以下 refund_top5_001、错误 transcript、归因均为本文为说明方法而构造的合成案例，不是 OpenAI 公开过的真实事件。

task:
  user_request: "过去 30 天退款率最高的 5 个产品是什么？"
claim: "Agent 能正确查询退款率"
environment:
  database: production_snapshot_2026_08_01
  permissions: user-scoped
  tools: [schema_search, sql_execute]
expected_outcome:
  top_5_products: [P-1042, P-0891, ...]
  refund_rate_definition: refund_orders / paid_orders
  date_range: [2026-07-09, 2026-08-08]
constraints:
  must_respect_user_permissions: true
graders:
  sql_semantic: { type: llm_grader, rubric: v2 }
  result_correctness: { type: code, compare: result_set_with_tolerance }
  permission_check: { type: code, rule: no_cross_user_tables }
  explanation_quality: { type: human_sampled }
metrics: [outcome_pass, policy_pass, partial_score, latency, token_cost]
failure_labels:
  [
    wrong_table,
    wrong_date_range,
    wrong_metric_definition,
    permission_violation,
    hallucinated_data,
  ]

一次失败 transcript（示意）：agent 把”退款率”算成 refund_amount / gmv，查了 orders 却漏了 refunds 表的权限过滤，输出了 top5。

Grader 判失败：result_correctness（结果集与 golden SQL 不一致）+ permission_check（一票否决）。
人工复核发现 grader 误判了一半：SQL 语义其实接近正确，错的是口径定义——归因按二维结构记为 Cause = Task（prompt 没写清退款率口径）+ Mode = Ambiguous spec，而不是模型推理错。
修正：prompt 显式声明口径 + grader 增加口径容忍说明 + 该 case 以 refund_top5_001 v3 进入 Regression Suite。

三条踩坑教训【原文】：Less is More（工具收敛合并，功能重叠对 agent 是困惑）；Guide the Goal, Not the Path（刚性指令把 agent 推向错误路径，和 τ²-bench 案例同一枚硬币）；Meaning Lives in Code（语义活在生产 pipeline 代码里，用 Codex 爬代码理解数据集构造）。另有权限透传 + 暴露推理证据链：系统侧不可越权，用户侧可自己核查。

语音场景一句话（Realtime Eval Guide）：Crawl（单轮回放）→ Walk（存档音频回放）→ Run（模型模拟多轮），dataset + graders + harness + 真实失败自动变新测试；投入 eval 的团队上线快 5–10 倍【原文】。

10.4 前沿模型评估已转向（压缩）

一句话案例【归纳自 10】：前沿模型评估已从”答对多少题”转向”在真实工具和高风险环境中会做什么”——重心是 capability / safety / monitorability / controllability（如 54,000 内部 Codex 任务部署模拟、Critical 网络能力定级、错位监控、红队、CoT 可控性）。注意：安全概述里没有常规准确率数字——这也反映出这类安全评估关注的问题与传统 accuracy benchmark 已经明显不同（此处是推论，不是 OpenAI 的原话表态）。

10.5 两家的侧重差异

维度	Anthropic	OpenAI
最强输出	Agent eval 术语与方法论（2）	数据质量审计 + 第三方评测规范（6）
核心概念	Transcript ≠ Outcome、pass^k、能力/回归分离、Swiss Cheese	Harness 即变量、五类效度威胁、弃权激励
对 agent	多回合改状态当一等公民	环境（harness）当一等变量
对数据	从真实失败出题、配参考解、双向平衡	直接审计公开 benchmark（30% 坏题）
安全感	多层叠加，接受单层必漏	可量化 + 可归因 + 第三方可复现
对”100%”	不谈，改用门禁 + 监控	明确论证达不到，转优化错误/弃权权衡
透明度	公开自家 eval 事故（3）	公开自家 benchmark 缺陷（6）
共同点	都要求 20–50 个真实失败起步，都强调读 transcript，都把 eval 当活资产，都用 agent 辅助质检

与其说竞争，不如说补同一张图的不同角落：Anthropic 解决”在具体 agent 产品里怎么管质量”；OpenAI 解决”当分数被全世界引用时怎么保证分数有效”。你两个都需要。

11. 如何自己搭：从 0 到 1 不需要平台

11.1 最小可跑（四文件起步）

eval/
  dataset.jsonl    # 20–50 个真实失败，每个带参考解
  runner.ts        # 跑任务、隔离环境、记 transcript.jsonl
  grader.ts        # 确定性 grader 为主 + 模型 grader 为辅
  report.ts        # 输出 pass@1 / pass^k / failure 分布

20–50 cases + 隔离执行 + 确定性 grader + transcript.jsonl

已经足够。Terminal-Bench 2.0 的 outcome-driven 设计就是证明：“测试验证指令结果是否在容器最终状态达成，不测命令或控制台输出”【原文】。

11.2 开源与业界工具地图

先定阈值，再选工具【推论】：

规模增加 → tracing → dataset management → concurrency →
experiment tracking → annotation

下面的分类直接对应正文模型：Task → Harness → Observation → Grader → Metric → Production。注意 Inspect AI、Harbor、DeepEval、Promptfoo、Ragas、Phoenix、Opik 各自解决的不是同一个问题——把它们统称”Eval Framework”会产生错误认知。

A. Benchmark / Foundation Model（测模型能力，不是测完整 Agent 系统）

lm-evaluation-harness（OSS，EleutherAI）：few-shot / zero-shot 标准 benchmark、多 backend（HF、vLLM、MPS）、task config——foundation model 能力的经典路线，正好强化”Benchmark ≠ Production Eval” 21。
OpenAI Evals / simple-evals（OSS）：前者是 framework + benchmark registry，值得读其 eval schema 与 benchmark 实现；后者官方已标注 2025 年 7 月后不再为新模型/benchmark 持续更新，仅保留 HealthBench、BrowseComp、SimpleQA 等 reference implementation——两者状态要分开看 22。
Inspect AI（OSS，UK AI Security Institute + Meridian Labs）：面向 coding / agentic / reasoning / knowledge / behavior / multimodal，强调 datasets、agents、tools、scorers 可组合原语，200+ 预构建 eval——从单轮评测进入 frontier / agent / safety eval 的入口 24。

B. Application / LLM Eval（偏测试框架路线）

DeepEval（OSS，Apache-2.0）：“Pytest for LLM apps”——测试用例、metric、CI gate 是一级对象，覆盖 LLM / RAG / conversation / agent；适合做 L3 Grader + Regression 开发框架，而非完整生产 observability 平台，直接对应 Failure → Eval → Fix → Regression 25。
Promptfoo（OSS）：Prompt / Model Regression + Red Team 工具，不是”另一个通用框架”——Prompt/Model/Attack 矩阵比较 + redteam init → run → report 工作流、插件与攻击策略、CI run context，对应 Regression + Adversarial + Harness 26。
Ragas（OSS）：不要只当”RAG 工具”——当前已覆盖 RAG / Agent / Text-to-SQL / Workflow / Prompt evaluation / Judge alignment / Benchmarking；选型问题不是”哪个框架最好”，而是”哪个覆盖我的 failure surface” 27。
UpTrain（OSS/平台）：开源 Evaluator 做记录与评估——轻量备选，不给 DeepEval / Promptfoo / Ragas 同等篇幅 28。

C. Grader / Evaluation Library（只解决评分层）

AutoEvals（OSS，Braintrust）：LLM-as-a-Judge + heuristic + statistical + factuality + safety，Python / TypeScript——只想快速获得一组可复用 grader 时用它；它是 grader library ≠ 完整 eval platform 29。
TruLens（OSS）：核心是 feedback functions——metric 可绑定到 trace 具体组件（question / context / retrieval / response），支持 online evaluation、sampling、throttling；Grader 不只是”给最终回答打分” 30。

D. Agent Evaluation / Harness（执行与沙箱层）

Harbor（OSS，Terminal-Bench 团队，Apache-2.0）= Execution / Sandbox / Rollout Harness，≠ Grader / Metric / Benchmark——评测任意 agent、大规模并发（本地 Docker / 云端 Daytona、Modal、E2B 等）、默认隔离（全新容器、任务无状态、默认禁用网络）；Harbor Hub 已扩展到 datasets / tasks / leaderboards / trajectories / rollouts。这些默认值恰好覆盖了 Anthropic 事故暴露出的典型风险：状态污染、意外网络访问和环境串扰 18 31。
对应关系：Inspect = Evaluation logic，Harbor = Execution / sandbox infrastructure——正好落回 L2/L3 分层。
Microsoft Prompt Flow（OSS/平台）：flow 编排、调试、tracing、evaluation、CI/CD、部署、监控，大数据集 evaluation——workflow-oriented Eval，与 DeepEval（test-oriented）形成对比 32。

E. Observability + Evaluation（追踪与实验层，不排名）

Arize Phoenix（OSS）：tracing、datasets、experiments、eval，偏 OpenTelemetry / OpenInference。
Opik（OSS，自托管）：tracing、evaluation、datasets、experiments、LLM-as-a-judge、production monitoring、pytest 集成，偏 tracing + eval + optimization 33。
Langfuse（OSS，自托管）：open-source observability / eval，有数据驻留/合规要求时优先。
W&B Weave（OSS/平台）：tracing、evaluation、experiment organization、production workflow，evaluation 代码主要在 weave/flow 34。
另有 LangSmith（LangChain 生态集成最顺）、EvalScope（文档，中文生态）按栈选择。很多团队是组合+自建小脚本，完全没问题（Anthropic 2 附录原话）。

F. Red Team / Security（对抗评估单独一类）

Promptfoo：adversarial testing / red teaming（见 B）。
Giskard（OSS，v3 已转向）：agent eval、多轮测试、red teaming、test generation、RAG evaluation、vulnerability scanning 35。
Inspect AI：safety / frontier evaluations（见 A）。

G. Cloud / Enterprise（云厂商原生 Eval）

云厂商 Eval 已从”模型 benchmark”进入”应用/Agent evaluation”：

Microsoft Foundry（商业）：Model / Agent / Dataset / Trace evaluation，offline + production，full conversation / individual turn，code rules + LLM-as-a-judge + human review + pairwise comparison——几乎逐项对应 Task / Dataset / Agent / Trace / Grader / Production 36。
AWS Bedrock Evaluations（商业）：foundation model（含 custom/imported）、RAG（retrieval 或 retrieve+generate 全链路）、LLM-as-a-Judge、programmatic evaluation 37。
另有 Google Vertex AI Evaluation、Braintrust（离线+线上打通）、Galileo（offline eval → production guardrail：production data → groundtruth → annotation → custom eval → guardrail，并把 expensive judge 压缩为低成本 Luna models，最贴合 Eval Flywheel）、Confident AI（DeepEval 的生产侧）按需选型。
反例提醒：Humanloop 已于 2025-09-08 sunset，不在推荐表——Eval 产品不只是技术问题，平台生命周期本身也是选型风险。

H. 工具 → 五层模型映射（覆盖面示意，不是排名）

工具	Task	Harness	Grader	Observability	Production
DeepEval	★★★	★	★★★	★★	★★
Promptfoo	★★★	★★	★★★	★	★★
Ragas	★★★	★	★★★	★★	★★
Inspect AI	★★★	★★★	★★★	★★	★
Harbor	★★	★★★	★	★★★	★
Phoenix	★★	★	★★★	★★★	★★★
Opik	★★	★	★★★	★★★	★★★
Langfuse	★★	★	★★	★★★	★★★
TruLens	★★	★	★★★	★★★	★★★
Prompt Flow	★★	★★★	★★	★★★	★★★
Foundry	★★★	★★★	★★★	★★★	★★★
Bedrock	★★★	★★	★★★	★★★	★★★

公开题集：SWE-bench Verified（有根本性设计与污染问题，慎用）、Terminal-Bench 2.0（89 任务，三位人工评审，前沿模型 <65%）、τ²-bench（政策+工具+任务+用户模拟器，榜单 taubench.com，仓库 14）。

按团队规模：小团队先指定每周读 transcript 的人；中型把通过率做成合并门禁；大型把 eval 结果带进发布评审。买不到的部分：前沿靶场、红队、第三方审计、生产规模流量、sandbagging 研究、公开缺陷的意愿——这些是资源与文化，不是工具。

反模式：先买平台再想测什么；把默认 scorer 当金标准；只看 dashboard 不读 transcript；跑一次 benchmark 当结论；以为买了工具就有了体系（本体永远是 L1 任务集）。

补充时效：OpenAI Evals 平台 2026-10-31 只读、2026-11-30 关停，新项目改用 Datasets（见 12）。

12. 最终原则

真正的问题不是”AI 能不能 100% 正确”，而是我们能不能把系统变成【归纳】：

可观察 → 可判定 → 可归因 → 可回归 → 可比较 → 可治理

并且形成：

生产失败 → 新的知识 → 新的 Eval → 新的约束 → 新的系统

所以可靠性不是一个模型属性，而是系统属性 + 测量体系属性 + 组织属性。

反向验证一张表（没做到哪环，就会付出对应代价）【归纳】：

没做到	后果
不可观察	根本不知道发生了什么
不可判定	知道结果，但不知道对不对
不可归因	知道错了，但不知道为什么
不可回归	修完不知道以后会不会再坏
不可比较	不知道新版本到底有没有改善
不可治理	知道有问题，但无法决定是否上线

最后一句 operational 的：能不能判定，是需求设计问题；能不能一直判定下去，是人和纪律的问题。 前者看 §3，后者看”每周谁读 transcript、每次事故是否新增 eval、发布评审是否看回归 diff”。

参考来源

开源与业界工具

Dev weekly 2026-Sep-07

Mon, 07 Sep 2026 02:02:03 GMT

AI and Programming

TimesFM-3: A zero-shot foundation model for multivariate forecasting

CS 329Z: Engineering AI Agents

zg 正式开源：本地检索，不止于关键词 https://zvec.org/en/docs/zvec-grep/embedding-models/

AI Search - free lesson

AI 搜尋前沿技術總覽: 哪些該做、哪些值得投入、哪些先知道就好

Claude 商务智能体

智能体请求暴增 9.4 倍，token 账单却没涨：Uber 公开 AI 软件工厂省钱方法

Introducing @huggingface/kernels: 200+ WebGPU Kernels for Local AI

OpenScholarXIV

Stop Letting Agents Run the Workflow

WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution

FrontierHarness Eval

zero-to-agent-30-Oreilly-FinanceAgent

AI Engineer Notebooks

How Warp builds self-improving agents on Claude

Anthropic最新多智能体研究观察到了三类系统性的失效模式 Patterns and problems in emerging multiagent systems https://www.anthropic.com/research/multiagent-systems

How people ask Claude for personal guidance

Agent-Native is an open-source TypeScript framework for building autonomous agents with intuitive UIs

Tangle - Build ML and data pipelines collaboratively

One Skills Repo, Every AI Agent: How Our Data Team Ships Its Conventions to Claude Code, GitLab Duo, OpenCode, and Snowflake CoCo

Node.js Interactive 2026: A Recap

shadcn 通过新推出的聊天组件将对话基础组件引入了 shadcn/ui

如何使用langsmith对ai agent和prompt进行测试（类似unit test或者integration test） “Dataset → Target → Evaluators → Experiment → Regression Comparison”，所以测试的是：output 是否满足 expectations

Snowflake Postgres: Zero-ETL from OLTP to Analytics

Others

阿里投资Kimi始末 - elsewhere

duck.ai by duckduckgo

人之恶，在好为人师

智谱与MiniMax背对背拥抱

Gartner Survey Finds Only 22% of Organizations Have Successfully Scaled AI Across Multiple Business Units

Dev weekly 2026-Aug-31

Mon, 31 Aug 2026 02:02:03 GMT

AI and Programming

DuckDB and the changing physics of analytics DuckDB 与不断变化的分析物理学

AWS收购DuckDB：鸭子飞进亚马逊雨林

WeMM-Embedding: WeChat Multi-Modal Embedding

The AI-Native SDLC playbook How to transform your software development lifecycle with AI—stage by stage.

When Smaller Models Win - Chess, LoRA, and the case for specialized AI

Anthropic内部AI Native经验公开

3x faster speeds on MLX - MTPLX

AI-enabled、AI First、AI Native: 一份 Excel 週報看懂五個階段

parqdb Billion-scale vector search, built on Parquet

Pretraining a Mini Kimi K3

《仙剑奇侠传 DOS 版》— Rust 移植

What is xy?

Qwen3.8-27B 本地部署

Architecture as a Socio-Technical Craft

community-driven exam preparation ExamCademy

Others

如此城市｜菜市场里的中国城市江湖

象神杀人案：为迎娶白月光，高智商程序员一人分饰多角，密谋除掉妻子和情敌

Dev weekly 2026-Aug-24

Mon, 24 Aug 2026 02:02:03 GMT

AI and Programming

吴恩达来信：人工智能工程技能地图

The making of Cursor’s icons

Detecting scraper bots through scroll behaviour

How Kenn is doing Agentic Engineering

What is a Harness?

ParqDB – Vector search in the browser from Parquet over HTTP

Where agent evals are going: Agent-as-a-Judge

Software engineering at a proprietary trading company: Optiver

Cumora by Yetone. Cross-platform team chat where AI agents are first-class participants alongside humans — same roster, same DMs, same group conversations, same Kanban board and calendar

Building an AI Text Detector From Scratch

Your Favorite Database Just Moved Into Snowflake’s House

DuckDB v2.0 正式预览：全新存储格式、查询快 2.3 倍，能直连 Postgres

Understand any codebase instantly 还是用的treesitter

grilling - agent skill

AI usage patterns in software teams

How Compaction Works in Pi

实时语音翻译 — 云端或完全离线在您的设备上运行

前 Jane Street 交易员：顶级交易机构如何建立 Edge

Open Foundry / OpenFoundry 开源项目调查对标 Palantir Foundry 的「运营智能+本体建模」赛道，但属于完全独立的两个开发团队、技术路线与产品定位差异极大

一场辩论之后，认真聊聊“本体论” by vonng https://patents.google.com/?q=(Tech)&assignee=Palantir&oq=Palantir+Tech&sort=new

本体论实践盘点：Palantir Ontology+Agent开源生态及3个开源项目进度

Others

日谈公园｜牛魔王是《西游记》里的西门庆

在线影视 feikuai

FLJ - Twitter Account Verification Platform

AI Agent interview questions

Sat, 22 Aug 2026 02:02:03 GMT

AI Agent 从 research demo 走上生产栈只用了约 18 个月。2026 年的面试早已不问「什么是 Agent」，而是问「你有没有上线过一个能在一周生产环境里存活、不靠烧钱跑飞工具调用的 Agent」。以下把今年高频面试题按主题归类，并附上真实的题库与资料来源，可作为复习清单。

1. 基础概念（几乎必问）

Agent 与 Chatbot 的本质区别：Chatbot 是「你问我答」的单向单次；Agent 是「感知 → 决策 → 行动 → 反思」的闭环，补上了工具、循环、记忆三样东西。
Agent 与传统 LLM Chain / Pipeline 的区别：Chain 是写死在代码里的线性固定流程（A→B→C）；Agent 根据中间结果动态决定下一步。

一句话：Chain 是被编排的，Agent 是自主决策的。

25 Agentic AI Interview Questions You Will Actually Get Asked (2026) — 从 phone screen 到 system design，强调「chain vs agent」是 autonomy over control flow
Top 35 Agentic AI Interview Questions and Answers (2026) — 基础 7 问：ReAct、Plan-and-execute、reflection、tool use、autonomous vs assisted
2026年AI Agent面试大揭秘（含真题及答案要点） — 基础概念类门槛题汇总

2. 核心推理模式：ReAct / Plan-and-Execute / Reflexion

ReAct（Reason + Act）：Thought → Action → Observation 循环，让下一步被真实数据 grounding，避免模型凭空向前幻觉。缺点是每个推理步都增加一次往返，有 token 成本与失控风险。
Plan-and-Execute：先写完整计划再执行，任务可清晰拆解时更便宜；ReAct 适合后续步骤依赖前面返回结果的探索性任务（调试、分析）。实际项目多混合：大方向用 Plan，每步内部用 ReAct。
Reflexion：执行后自我反思，把教训记下来供下次参考，而非盲目重试。成本约翻倍，需客观指标（测试通过率、完成度）验证反思是否有效，而非看 Agent 主观判断。
2026大厂AI Agent高频面试题Top50（题目+参考答案+追问陷阱） — Q9–Q18 专讲 Agent 核心架构，含手写 ReAct 核心循环
25 Agentic AI Interview Questions — Q7：什么时候不该用 ReAct（延迟敏感、任务简单、需要高度确定性）

3. 工具调用与协议：Function Calling / MCP / A2A

Function Calling：把工具描述（名称、用途、参数 schema）传给 LLM → LLM 决定调用并提取参数 → 系统执行 → 结果回传 LLM。难点在 schema 设计与错误处理。
MCP（Model Context Protocol）：Anthropic 提出的开放协议，标准化 Agent 与外部工具的连接，类比「USB 接口」——统一接口、降低集成成本、生态可扩展。2026 年很多公司用它替代手写工具接入层。
A2A（Agent-to-Agent）：Agent 间通信协议，解决多 Agent 协作时的分工、中间结果传递与冲突处理，仍属早期探索。
2026年AI Agent面试大揭秘 — Q8–Q10：Function Calling 流程、MCP 为何重要、A2A 概念
Top 35 Agentic AI Interview Questions — Q10：RAG 与 tool-calling 的区别及选型

4. RAG 与记忆系统

RAG 流程：文档分块 → 向量化 → 存入向量库 → 检索相关片段 → 拼接上下文生成。高频追问：Hybrid Search（关键词+向量）、Rerank、GraphRAG。
记忆分层：短期记忆 = 上下文窗口内；长期记忆 = 外部存储（向量库 / 知识图谱 / 文件），按需检索。核心不是「存得多」而是「取准」。
持久化记忆设计需区分：in-context 短期记忆、episodic（结构化历史交互）、semantic（向量检索的可嵌入知识），并解决上下文增长时的压缩/摘要与陈旧冲突。
25 Agentic AI Interview Questions — Q5：长运行 Agent 的持久化记忆设计
2026大厂AI Agent高频面试题Top50 — Q28–Q40：RAG 与检索增强、Q36–Q40：记忆与上下文管理

5. 多 Agent 协作

单 Agent 适合线性任务；多 Agent 适合并行处理与需要制衡的场景（写代码 / 写测试 / 审查并行）。不要为炫技上多 Agent——先确认单 Agent 确实做不好再拆分。
任务分发三模式：路由（Orchestrator 按类型分发）、Swarm（并行处理投票选优）、流水线（A→B→C 有明确先后依赖）。
2026年AI Agent面试大揭秘 — Q13–Q14：单/多 Agent 选型与任务分发
Top 35 Agentic AI Interview Questions — 多 Agent 协作与成本/通信开销权衡

6. 生产实战（压轴题，区分背八股与真干过）

死循环：设硬上限（最大迭代 10–15、超时、token 预算红线）；检测重复无新信息的工具调用；恢复分三档（插提示换思路 / 压缩摘要重启 / 降级转人工）。reflection 失败 3 次必须熔断。
幻觉：三层防线——输入层给足上下文与参考资料；执行层关键输出用工具验证；输出层设审查 Agent 做一致性检查。
成本控制：模型路由（简单任务小模型，复杂任务才上大模型）、上下文裁剪、缓存相同/相似查询、迭代限制。
Prompt Injection：输入清洗、系统提示与用户输入隔离不可覆盖、不可逆动作前做输出校验、沙箱化工具执行、最小权限原则。
25 Agentic AI Interview Questions — Q3 工具调用失败处理、Q8 prompt injection 防护、Q9 成本高效 Agent
Top 35 Agentic AI Interview Questions — Q6 为什么 Agent 会无限循环及如何停止
2026京东健康AI Agent工程师面试题库（Java 技术栈） — 一线到三面完整答案，含 Spring AI / LangChain4j 架构与护栏设计