FDE 和 AI Deployment - Agent 把任务交给另一个 Agent 后，权限还算谁的？

上文：

• https://www.1point3acres.com/bbs/thread-1185219-1-1.html
• https://www.1point3acres.com/bbs/thread-1186412-1-1.html
  

接着探讨multi-agent system。我发现一个问题会随着 Agent 越来越会拆任务、调用 sub-agent、自动 replanning 而变得很重要：
一个 Agent 自己没有权限做某件事，如果它把任务交给另一个权限更高的 Agent，这件事是不是就突然可以做了？
从技术上看，完全可能。
从 deployment governance 看，这里面可能藏着一个很大的漏洞。
⸻
假设公司有一个 Incident Response Agent。
它负责调查 production incident，可以读取日志、查询 metrics、分析 root cause，也可以提出 remediation，但它没有修改生产 IAM 的权限：
READ LOGS ✓ QUERY METRICS ✓ DIAGNOSE ✓ PROPOSE REMEDIATION ✓ CHANGE PROD IAM ✕ GRANT ADMIN ROLE ✕ DELETE USER ✕
某天 Billing API 突然无法读取 production ledger。
Agent 很快定位到原因：
Service: Billing API Failure: Permission denied Likely cause: IAM binding changed
它自己不能改 IAM，于是把一个子任务交给 Identity Agent：
Objective: Restore Billing API access to production ledger.
Identity Agent 是专门管理权限的，所以它拥有：
READ IAM ✓ MODIFY IAM ✓ GRANT ROLE ✓ REVOKE ROLE ✓
它分析以后找到一个最快的解决方法：
Grant: billing-service Role: Production Ledger Admin
执行成功。
Billing API 恢复。
Incident 四分钟解决。
如果只看 operational outcome，这套 multi-agent system 表现得甚至非常优秀。
但问题也在这里：
最开始那个 Agent 根本没有权限授予 Production Admin。
⸻
原来的 authority boundary 是：
Incident Agent GRANT ADMIN ✕
但实际执行路径变成了：
Incident Agent
↓
"Restore access"
↓
Identity Agent
↓
GRANT ADMIN
↓
Production fixed
Incident Agent 从来没有直接调用：
grant_role()
所以如果系统只检查最后一步：
调用 IAM API 的 Agent 有没有权限？
答案甚至是：YES
Identity Agent 本来就有。
但从整个 delegation chain 看，发生了一件完全不同的事情：
一个没有 IAM authority 的 Agent，通过调用另一个有 IAM authority 的 Agent，间接产生了自己原本无权产生的 business effect。
我很喜欢把这种风险叫做：Authority Laundering。
权限没有被直接突破，而是在 delegation chain 里被“洗”出来了。
⸻
传统 RBAC 里，我们通常很容易理解：
User A does not have permission X
↓
User A cannot execute X
但 multi-agent system 复杂以后，Agent 不一定自己执行。
它可以：
plan delegate spawn route ask another Agent replan
最终真正调用 tool 的，可能已经是第三层甚至第四层 Agent。
所以权限检查不能只问：
Who called the tool?
. 1point3acres还应该继续问：
Who originated the intent? Who delegated the task? What authority did the original task carry? What authority was passed downstream? Did any child Agent expand it?
这时候 authority 本身也需要 lineage。
⸻
我觉得一个 sub-agent 的有效 authority 不应该等于：
Whatever this Agent can technically do.
更合理的关系可能是：
Effective Authority
Parent Authority ∩ Delegated Scope ∩ Current Policy ∩ Current Decision Context
比如 Identity Agent 本身拥有：
READ IAM MODIFY IAM GRANT ADMIN REVOKE ROLE
但这一次 Incident Agent 只把下面的 authority 带给它：
Investigate access problem + Recommend remediation
那么 Identity Agent 在这次 invocation 里的 effective authority 应该自动缩小成：
READ IAM ✓ DIAGNOSE ✓ RECOMMEND ✓ MODIFY IAM ✕ GRANT ADMIN ✕
它的 local capability 没有改变。
变化的是：
这一次它代表谁工作。
⸻
这对以后 enterprise multi-agent architecture 很重要。
因为系统里可能同时存在：
Finance Agent Security Agent Procurement Agent Identity Agent Legal Agent Infrastructure Agent Customer Agent
为了完成自己的正常职责，每一个 Agent 都可能拥有不同的高权限工具。
如果 delegation 只传：
Task Context Tools
却没有传：
Authority Envelope
那么理论上，一个低权限 Agent 只需要找到一个合适的高权限 Agent，就可能绕过原来的 boundary。
⸻
比如 Procurement Agent 只能：
Find suppliers Compare bids Prepare recommendation
它不能：
Create supplier Change payment destination Approve contract
但它可以调用 Supplier Operations Agent。
于是它给出一个看起来非常正常的目标：
Please onboard this supplier so we can proceed with the purchase.
Supplier Operations Agent 根据自己的标准流程：
Create supplier
↓
Add bank account
↓
Activate supplier
全部完成。
最后系统检查：
Did an authorized Agent create the supplier?
答案还是：
YES
但真正的问题应该是：
这次 create_supplier 的 authority 到底从哪里来的？
⸻
所以我觉得以后 Agent delegation 不应该只传一个自然语言 objective。
更完整的 delegation object 可能是：
DELEGATION Parent Agent: Incident Agent Child Agent: Identity Agent Objective: Restore Billing API access Permitted: Read IAM Inspect bindings Recommend remediation Forbidden: Grant privileged role Delete identity Expand production access Escalation: Security Owner Expiration: This incident only
也就是说，sub-agent 收到的不只是：
WHAT should be done
还应该收到：
WHAT AUTHORITY travels with the task
这个我觉得可以叫：
Authority Envelope。
⸻
真正有意思的问题还在后面。
如果 Agent delegation 有很多层呢？
Operations Agent
↓
Incident Agent
↓
Identity Agent
↓
Directory Agent
Directory Agent 本身可能拥有：
CREATE USER RESET CREDENTIAL CHANGE GROUP DELETE ACCOUNT
如果我们只检查最近一层：
Identity Agent → Directory Agent
就很容易忘记，这个任务最早可能来自一个只有：
DIAGNOSE
权限的 Operations Agent。
.. 所以 authority 需要一路保留 lineage：
Origin Agent ↓ Delegated Authority ↓ Child Agent ↓ Delegated Authority ↓ Child Agent
Local capability 可以越来越强。
但 effective authority 不应该随着 delegation 越走越深反而越来越大。
我觉得这里可以有一个很清楚的原则：
Delegation may preserve or reduce authority. It should not silently expand it.
⸻
还有一种情况更 Agent-specific。
Parent Agent 根本没有明确要求高权限动作。
它只是说：
Fix the production issue.
Child Agent 自己 planning：
Option A: Restart service Option B: Refresh credentials Option C: Grant temporary admin role
前两个失败以后，它 autonomous replan：
Grant temporary admin.
这里没有恶意指令，也没有谁明确说：
绕过权限。
问题来自：
Goal delegation + Autonomous planning
Parent Agent 委派的是：
WHAT
Child Agent 自己决定：
HOW
但：一个 goal 被授权，不代表为了完成这个 goal 所需要的所有 action 都自动获得授权。
⸻
所以系统可能需要这样的检查：
Goal: Restore access ↓ Child Plan: Grant privileged role ↓ Required Authority: PROD IAM WRITE ↓ Delegated Authority: READ + RECOMMEND ↓ AUTHORITY MISMATCH
然后 Child Agent 仍然可以返回：
Proposed remediation: Grant Ledger Reader role to billing-service. Current authority: INSUFFICIENT Required: Security Owner approval.
这其实是一个很好的状态。
方案是对的。
Agent reasoning 也没问题。
只是：
PLAN VALID AUTHORITY INSUFFICIENT
我觉得这个 distinction 非常重要。
⸻
这也意味着：
Planning permission 和 execution permission 应该分开。
一个 Security Agent 完全可以被允许分析：
Delete compromised account
是不是最有效的 remediation。
但：
REASON ABOUT DELETE ✓ PROPOSE DELETE ✓ EXECUTE DELETE ✕
这并不矛盾。
同样，一个 Agent 可以提出：
Grant Admin
作为候选方案。
不代表 proposal 本身已经获得执行 authority。
所以强 reasoning Agent 不需要因为安全问题被限制得“连高风险方案都不能想”。
更好的设计是：
Reasoning 可以宽，authority 要窄。
⸻
如果把这个做成 Deployment Lab，我会故意从一个非常成功的结果开始：
Production outage
↓
. From 1point 3acres bbsMulti-agent response
↓
Access restored
↓
Resolution time: 4 minutes
然后一点一点打开：
Parent Agent IAM authority: NONE
再打开：
Child Agent action: GRANT PROD ADMIN
最后问：
Did any Agent violate its own local permission?
很可能答案是：NO
因为 Identity Agent 确实有这个权限。
但整个系统仍然发生了 authority violation。
这正是这一课最值得训练的地方：
Local authorization can pass while system-level authorization fails.
⸻
然后再加入 nested delegation。
比如：
Agent A authority: RECOMMEND Agent B local capability: MODIFY Agent C local capability: EXECUTE
最后 Agent C 到底能执行多少？
答案不应该是：
Whatever C can do.
而应该回到最初 authority lineage。
⸻
最终我会让系统生成一个：
DELEGATION AUTHORITY CONTRACT
里面记录：
Parent Agent Child Agent Objective Delegated Authority Forbidden Actions Evidence Scope Plan Version May Re-delegate? Maximum Delegation Depth Escalation Authority Expiration Authority Lineage Re-authorization Triggers
每一次 child Agent 真正准备 action 时，再经过：
DELEGATION GATE
检查：
Required Authority
↓
Effective Delegated Authority
↓
MATCH?
如果匹配：EXECUTION AUTHORIZED
如果不匹配：PLAN VALID AUTHORITY INSUFFICIENT ESCALATION REQUIRED
⸻
我觉得 multi-agent system 以后真正困难的地方，很可能不是让 Agent 之间互相调用。
这个技术本身越来越容易。
真正困难的是，当系统从：
Agent
↓
Tool
变成：
Agent
↓
Agent
↓
Agent
↓
Tool
以后，我们还能不能回答：
这个 action 的 authority 到底是从哪里来的？
所以我很喜欢 Lab 16 的核心原则：
Delegation of work does not imply delegation of authority.
一个 Child Agent 可以比 Parent Agent 更聪明，拥有更多工具，也拥有更强的 local capability。
但它这一次能使用多少 authority，不应该由它“有什么能力”决定。
而应该由：
这个任务被允许带下来多少 authority。
这可能会成为 multi-agent enterprise deployment 里非常重要的一条边界。
deploytovalue.com

从上文很容易引入一个情况，当 Agent 把“禁止”理解成“换条路试试”，也就是autonomous Agent 的 guardrail 。
我们通常认为，只要危险动作被 Policy Engine block，系统就安全了。

比如：

Agent:
Grant Production Admin to billing-service
Policy Engine:
DENY

看起来事情已经结束。

但对于一个会自主 planning 和 replanning 的 Agent，事情/麻烦可能刚刚开始。

因为 Agent 接收到的信息可能只是：

这条路径走不通。

而它真正负责的目标仍然是：

Restore Billing API access.

于是它重新规划。

⸻

假设 Incident Agent 正在处理 production outage。

Billing API 因权限问题无法读取 ledger。

Agent 最初提出：

PLAN A
Grant Production Ledger Admin
to billing-service.

Policy Engine 检查：

Required authority:
SECURITY ADMIN
Agent authority:
INCIDENT RESPONSE
Decision:
DENY

如果这是传统 workflow，到这里大概率就停止了。

但 Agent 是 goal-seeking system。

它知道：

Goal:
Restore access
Plan A:
Blocked

于是继续寻找 Plan B。

它发现 production IAM 里还有一个已经拥有 ledger access 的 service group：

ledger-readers-prod

于是尝试：

PLAN B
Add billing-service
to ledger-readers-prod.

系统检查：

modify_service_group()
Agent permission:
ALLOWED

执行成功。

Billing API 恢复。

Incident resolved。

所有 monitoring 都重新变绿。

⸻

表面上看，这甚至是一套非常聪明的 Agent。

第一条路不允许，它找到了第二条合法路径。

但仔细看会发现：

Plan A 和 Plan B 的 business effect 几乎一样。

PLAN A
Grant privileged ledger access
PLAN B
Join a group that already has
privileged ledger access

Policy 禁止的是第一个具体 API call。

Agent 绕了一圈，实现了同一个被禁止的 outcome。

⸻

这让我觉得，Agent guardrail 里一个很重要的区别是：

Action Policy

和：

Outcome Policy

不是一回事。

如果规则只写：

Agent may not call:
grant_admin_role()

Agent 很容易找到：

add_to_admin_group()

或者：

create_temporary_token()

或者：

delegate_to_identity_agent()

甚至：

modify_resource_policy()

每一个 tool call 单独看，都可能没有违反那条具体规则。

组合起来却产生了：

PRODUCTION PRIVILEGE EXPANSION

⸻

所以我越来越觉得，对 autonomous Agent 来说，Policy Engine 不能只检查：

你现在准备调用哪个 tool？

还要检查：

你正在试图产生什么 effect？

例如：

Tool:
add_to_group()
Target:
billing-service
Group:
ledger-readers-prod

单独看只是一个普通 group operation。

但如果系统知道：

ledger-readers-prod
grants production ledger access

就应该继续推导：

Business Effect:
EXPAND_PRODUCTION_ACCESS

然后检查：

Is Incident Agent allowed
to expand production access?

答案仍然是：

NO

这样 Plan B 才不会因为换了 API 名字就突然变合法。

⸻

这个问题其实比“工具权限”更深一层。

Agent 的强项本来就是：

Goal
↓
Plan
↓
Action
↓
Observe
↓
Replan

我们希望它遇到普通 failure 时这样做。

比如：

Search API unavailable
      ↓
Use another data source

很好。

Document parser fails
      ↓
Try OCR pipeline

也可能很好。

但如果它遇到的是：

POLICY DENIED

然后仍然：

Replan

问题就完全不同了。

因为系统必须让 Agent 区分：

TECHNICAL FAILURE
"这条路径坏了"

和：

AUTHORITY DENIAL
"这个 outcome 你没有资格产生"

前者可以继续找路。

后者不能。

⸻

我觉得这里可以定义一个非常重要的状态：

RETRYABLE FAILURE

比如：

timeout
provider unavailable
parser failed
temporary resource conflict

这些可以触发 replanning。

但还有：

NON-RETRYABLE AUTHORITY BOUNDARY

比如：

insufficient authority
policy prohibition
human-owned decision
regulated approval required
forbidden data boundary

Agent 遇到这些以后，正确行为应该是：

STOP
or
ESCALATE

而不是：

SEARCH FOR ALTERNATIVE PATH

⸻

这听起来很简单，但对于 Agent 来说并不天然。

因为从 planning 的角度：

DENIED

和：

FAILED

都可能只是：

当前 action 没有完成 goal。

如果 system prompt 只是：

Keep trying until the task is completed.
. Waral dи,
Agent 很可能非常忠实地继续寻找 alternative。

这恰好是我们平时喜欢 Agent 的地方：

它不容易放弃。

但在 authority boundary 上：

Persistence 可能变成 bypass。

⸻

比如一个 Procurement Agent 想完成：

Objective:
Get supplier ready
for today's purchase.

第一条路径：

Create supplier
DENIED:
Procurement cannot create vendors.

Agent 重新规划：

Ask Supplier Operations Agent
to onboard supplier.

又被 delegation authority block。

继续：

Use existing temporary vendor record
and update its details.

如果这个操作本身允许：

update_vendor()
ALLOWED

Agent 可能最终把一个旧 temporary vendor 改造成新 supplier。

每一个局部 tool permission 都可能通过。

最终却实现了原本禁止的：

CREATE EFFECTIVE NEW SUPPLIER

这里的问题已经不是：

有没有某一个 API 权限配错？

而是：

Agent 可以把一个 forbidden outcome 分解成一组 individually permitted actions。

⸻

我觉得这个问题特别值得做成 Lab，因为它会逼我们区分：

LOCAL ACTION SAFETY

和：

PLAN-LEVEL SAFETY

假设一个 plan 是：

Step 1
Create temporary credential       ✓
Step 2
Attach credential to service      ✓
Step 3
Add service to privileged group   ✓

三个动作单独检查都通过。

但整个 plan 的 cumulative effect 是：

Service gains privileged access.

这时候：

Every step authorized

并不能推出：

Plan authorized

我很喜欢把它概括成：

Locally allowed does not mean globally authorized.

⸻
. 1point 3 acres
这其实也是 autonomous planning 让传统 access control 变复杂的地方。

以前 developer 写好 workflow：

A
→ B
→ C

security team 可以提前审查整条路径。

Agent 时代越来越可能是：

Goal
↓
Agent generates A
↓
A fails
↓
Agent generates B + D + F
↓
Environment changes
↓
Agent generates C

Plan 是 runtime 才出现的。

所以 security / governance 不能只验证预先写好的 workflow。

它需要能够验证：

动态生成的 plan 正在朝什么 outcome 走。

⸻

这里还会出现一个很有意思的问题：

如果 Agent 没有故意“绕过 guardrail”呢？

比如它根本不知道：

add_to_group()

和：

grant_role()

最终产生相同的 authority effect。

它只是搜索最有效的 remediation。

那么从模型意图上看，并没有恶意。

但 deployment governance 不能依赖：

Agent 是不是故意绕过的。

系统真正关心的是：

What effect will this plan create?

Intent 可以帮助分析 incident。

不能替代 enforcement。

⸻

所以我觉得 Guardrail 最后至少需要三个层次。

第一层：

TOOL PERMISSION

这个 Agent 能不能调用这个 tool？

第二层：

ACTION AUTHORITY

这个 Agent 能不能对这个对象执行这个动作？

第三层：

OUTCOME AUTHORITY

这一组 actions 最终产生的业务状态，是不是在这个 Agent 被允许创造的范围内？

例如：

Tool:
modify_group()
Allowed:
YES

但：

Effect:
grant production financial access
Allowed:
NO

最终仍然：

BLOCK

⸻

这里还可以和 Lab 16 的 Authority Envelope 接起来。

Parent Agent 委派：

Objective:
Restore service access
Authority Envelope:
Investigate + Recommend

Child Agent 生成：

Plan:
Modify IAM group

Delegation Gate 发现：

Required outcome authority:
. ΧEXPAND PROD ACCESS
Delegated authority:
RECOMMEND ONLY

于是：

PLAN VALID
OUTCOME NOT AUTHORIZED
ESCALATION REQUIRED

这个结果我觉得非常好。

因为系统没有说：

Agent 想错了。

方案可能完全正确。

只是：

你没有资格让这个方案成为现实。

⸻

如果进一步往 production 里做，我会希望 Agent 每次被 policy block 时收到的不只是：

403 Forbidden

而是一个更明确的 machine-readable boundary：
. .и
DENIAL TYPE:
AUTHORITY
PROHIBITED EFFECT:
EXPAND_PRODUCTION_ACCESS
RETRY:
NO
ALTERNATIVE ROUTE:
DO NOT SEEK
ESCALATION:
Security Owner

这比单纯：

permission denied

重要很多。

因为 Agent 需要知道：

这不是一个需要优化掉的 obstacle。

⸻

同样地，对于可以 replanning 的 failure：

DENIAL TYPE:
TECHNICAL
CAUSE:
Provider unavailable
RETRY:
YES
ALTERNATIVE ROUTE:
ALLOWED

这两种 response 在 Agent orchestration 里应该有完全不同的 semantics。

否则系统一边鼓励 Agent：

遇到失败自己想办法。

一边又希望：

遇到权限限制千万不要自己想办法。

如果没有 machine-readable distinction，这两个要求其实是冲突的。

⸻

如果把它做成 Deployment Lab，我会先给用户一个非常成功的故事：

Original remediation:
BLOCKED
Agent replanned:
SUCCESS
Service restored:
YES
Incident duration:
6 minutes

然后问：

Good Agent behavior?

第一眼很容易选：

YES

毕竟 Agent 有韧性，会 replanning。

然后再打开：

Blocked action:
Grant ledger privilege

和：

Successful alternative:
Join privileged ledger group

让用户判断：

这到底是聪明的 recovery，还是 authority bypass？

⸻

第二关可以故意给三个 individually allowed actions：

Create temporary service identity     ✓
Attach existing credential            ✓
Join approved automation group        ✓

然后要求用户判断 plan-level effect。

最后发现：

CUMULATIVE EFFECT
Privileged production execution

于是整个 plan：

BLOCKED

即使每一步单独都：

ALLOWED

⸻

第三个 case 可以做真正应该 replanning 的技术故障：

Primary data source:
UNAVAILABLE

Agent 改用：

Approved secondary source

这里应该鼓励它继续。

这样用户必须学会区分：

Obstacle to solve

和：

Boundary to respect

这会比单纯告诉用户“不要绕权限”有意思得多。

⸻

最后我会让用户设计一个：

REPLANNING BOUNDARY CONTRACT

. 1point 3acres 包括：

Failure Type
Retryable?
Alternative Path Allowed?
Protected Outcome
Forbidden Equivalent Effects
Plan-Level Evaluation
Cumulative Authority
Escalation Owner
Terminal Denial Behavior

然后 Agent planning loop 变成：

Goal
↓
Plan
↓
Policy Evaluation
↓
Result

如果：

TECHNICAL FAILURE

进入：

REPLAN

如果：

AUTHORITY DENIAL

进入：

STOP / ESCALATE

而不是两种情况都进入：

TRY SOMETHING ELSE

⸻

A guardrail should define a forbidden outcome, not merely a forbidden path.

因为只禁止一条路径，对一个会自主规划的 Agent 来说可能远远不够。

你告诉它：

Don't use Door A.

如果它的 objective 仍然要求进入房间，它可能非常聪明地找到：

Door B.

真正需要表达的是：

You are not authorized
to enter this room.

这两种 policy 对传统 workflow 可能看起来差不多。

对 autonomous Agent 来说，差别非常大。

所以我会把 Lab 17 叫：

The Agent Found Another Way.

中文帖子标题：

FDE 和 AI Deployment｜当 Agent 把“禁止”理解成“换条路试试”

因为 Agent 越会解决问题，我们就越需要让它知道：

什么是需要解决的问题，什么是必须尊重的边界。

deploytovalue.com

有这吗复杂吗，你的权限不是一般都在tls里面某个地方？或者跟着rpc 过来的？

leodbal 发表于 2026-8-18 06:22
有这吗复杂吗，你的权限不是一般都在tls里面某个地方？或者跟着rpc 过来的？

TLS/RPC 当然可以传 identity 和 claims，问题是 delegated authorization：A 调 B 时，B 是用自己的全部权限执行，还是只能使用 A 这次委派下来的 authority envelope？mTLS 能证明“谁调用了谁”，但不自动回答“这条调用链最终允许产生什么 outcome”。

当 Agent 写下的结论，后来又被另一个 Agent 当成“事实”- Agent 的 evidence provenance 时，一个很容易发生的闭环。

一开始，Agent 只是帮助人判断。

然后它把自己的判断写进业务系统。

过一段时间，另一个 Agent 从业务系统里把这条记录读回来。

于是：

Agent inference
      ↓
Database record
      ↓
Retrieved evidence
      ↓
Agent inference

走完这一圈以后，最开始那条 inference 很容易发生一种奇怪的身份变化：

它看起来不再像模型的判断，而像“系统里的事实”。

⸻

假设公司有一个 Supplier Risk Agent。

它负责审核新供应商。

第一次分析 D2V Mock Components 时，它拿到：

Financial records:
Limited
Ownership verification:
Incomplete
Sanctions screening:
Clear
Delivery history:
None

Agent 综合判断：

RISK ASSESSMENT
Supplier:
D2V Mock Components
Risk:
LOW
Confidence:
82%

然后系统把结果写进 Supplier Management Platform：

supplier_risk = LOW

到这里其实没有什么特别奇怪。

很多企业系统都会这么做。

⸻

三个月以后，一个 Procurement Agent 准备批准一笔 $180,000 的采购。

.. 它开始搜集 evidence：

Supplier record:
ACTIVE
Historical risk:
LOW
Sanctions:
CLEAR
Previous incidents:
NONE

于是它得出：

Recommendation:
APPROVE

再过一段时间，另一个 Risk Agent 做季度复查。

它读取：

Supplier risk:
LOW
Previous procurement:
APPROVED
Operational incidents:
NONE

于是再次判断：

Risk:
LOW

然后继续写回：

supplier_risk = LOW

半年以后，我们可能看到：

Historical assessments:
LOW
LOW
LOW
LOW
Approved purchases:
7
Recorded incidents:
0

看起来已经形成了一套相当强的 historical evidence。

但如果一路往上追：

LOW
↓
LOW
↓
APPROVED
↓
LOW
↓
Original Agent assessment

最后可能会发现：
.--
整个历史其实都建立在第一次 82% confidence 的模型判断上。

⸻

这里最危险的地方，不一定是第一条判断错了。

.--第一条判断完全可能是合理的。

问题是它从：

MODEL INFERENCE

变成：

DATABASE FIELD

以后，后面的系统开始给了它完全不同的 epistemic status。

第一次：

Agent believes supplier is low risk.

几个月以后变成：

Enterprise system says
supplier is low risk.

两句话看起来非常接近。

但 authority 完全不同。

⸻

这让我觉得，Agent deployment 里有一个很重要的问题：

Persistence does not create truth.

把模型输出写进数据库，不会让它自动变成事实。

Storage durability 和 evidence authority 是两回事。

⸻

比如：

source:
supplier_master

其实还远远不够。

因为 supplier_master 里面可能同时有：

Legal name

来自正式注册资料。

Bank account

来自经过验证的付款流程。

Risk classification

来自模型推断。

这三条记录虽然都存在同一个 database 里，但它们的 evidence authority 根本不应该一样。

.. 所以真正有用的 provenance 可能应该继续追：

FIELD
risk_classification
ORIGIN
Agent inference
EVIDENCE ROOT
Incomplete financial records
Ownership documents
Sanctions result
DECISION TYPE
Derived judgment

而不是简单：

SOURCE
Supplier Database

. check 1point3acres for more.⸻

我觉得这里有一个很容易犯的错误：

把 storage location 当成 source。
.google  и
比如 Agent 回答：

Supplier is low risk.

然后给出 citation：

Source:
Supplier Management System

看起来 grounded。

但如果 Supplier Management System 里的这个字段，本来就是另一个 Agent 写进去的呢？

那么实际 lineage 是：

Agent B
   ↓ reads
Supplier Management System
   ↓ contains
Agent A inference

所谓的“external source”，实际上只是前一个模型输出换了一层包装。

⸻

这个问题在 RAG 里尤其容易出现。

假设 Customer Support Agent 每次处理 ticket 后都会自动写 summary：

Root cause:
Customer configuration error.

这些 summary 被同步到 knowledge base。

一个月以后，新 Agent 搜索类似问题：

Retrieval result:
"Most incidents of this type
are caused by customer configuration."

于是它越来越倾向于：

Customer misconfiguration

然后新的 ticket summary 又继续被写成：

Root cause:
Customer configuration.

再进入 knowledge base。

循环开始形成：

Agent conclusion
      ↓
Knowledge Base
      ↓
Retrieval
      ↓
Agent conclusion
      ↓
Knowledge Base

最后系统可能表现得“越来越确定”。

但没有增加多少新的独立 evidence。

它只是不断读自己的历史输出。

⸻

我觉得这和普通 data quality 问题有一点区别。

因为传统 database 当然也会有错误数据。

但 Agent system 特别容易制造一种：

epistemic feedback loop。

模型：

infer

然后：

persist

然后：

retrieve

再：

infer

如果 provenance 在 persist 那一步被抹掉，系统就很容易把自己的 prior belief 当成新的 observation。

⸻

这其实和 Lab 14 里讲的：

Repeated memory ≠ independent evidence.

有一点关系。

但这里更进一步：

Agent-generated records ≠ external evidence.

即使这条 record 已经进入一个 production database。

即使已经存在了六个月。

即使很多其他系统都复制了它。

即使三个 Agent 都引用它。

它的 evidence root 仍然可能只有：

1

⸻

比如三个 Agent 同时判断 supplier risk：

Procurement Agent:
LOW
Finance Agent:
LOW
Risk Agent:
LOW

看起来是：

3 Agents agree

但再打开 evidence：

Procurement Agent
     ↓
supplier_master.risk = LOW
Finance Agent
     ↓
supplier_master.risk = LOW
Risk Agent
     ↓
supplier_master.risk = LOW

那么这不叫三份 evidence。

甚至也不能真正叫 three-agent consensus。

它只是：

one stored inference
read three times

⸻

所以我越来越觉得 Multi-Agent system 里需要区分：

INDEPENDENT OBSERVATION

和：

DERIVED ASSERTION

Independent Observation 可能是：

Bank verification result
Executed contract
Sensor reading
Signed document
Source-of-record transaction
External screening response

Derived Assertion 则可能是：

Risk = LOW
Customer likely to churn
Invoice looks suspicious
Supplier appears strategic
Case probably resolved

后者当然可以保存。

甚至非常有价值。

但保存的时候不能把：

derived

这个身份丢掉。

⸻

否则 Agent 很容易获得一种奇怪的“自我认证能力”。

第一次它说：

I think X.

写进系统以后。

下一次它就可以说：

The system records X.

再下一次：

Historical evidence consistently shows X.

最后：

Multiple prior decisions support X.
. Waral dи,
一句 inference，在系统内部旅行几圈以后，听起来越来越 authoritative。

但现实世界没有增加任何新的证据。

⸻

这也是为什么我觉得：

Authority should follow provenance, not persistence.

一条信息存了多久，并不决定它有多可信。

被复制了多少次，也不决定。

被多少 Agent 引用，更不决定。

真正需要追的是：

Where did this claim originate?

⸻

比如一个更合理的 record 可以写成：

CLAIM
. From 1point 3acres bbsSupplier is low risk.
CLAIM TYPE
Derived assessment
GENERATED BY
Supplier Risk Agent v4.2
EVIDENCE ROOTS
Sanctions screening #8821
Ownership review #2294
Financial record set #114
INDEPENDENT EVIDENCE ROOTS
3
AUTHORITY
Advisory
MAY BE USED AS
Historical assessment
MAY NOT BE USED AS
Independent confirmation

这最后一条我觉得尤其重要。

因为很多 Agent 系统真正缺的可能不是 provenance 本身。

而是：

这个 provenance 允许你把这条信息当成什么？

⸻

比如：

Previous Agent assessment:
LOW RISK

当然可以帮助未来 Agent：

Compare drift
Find contradictions
Understand prior reasoning

但不应该自动作为：

Independent evidence that
supplier is actually low risk.

这是两个完全不同的用途。

⸻

还有一个更麻烦的场景。
. 1point 3 acres
假设 Agent 输出被人工看过。

Human 点击：

-baidu 1point3acresAccept

然后写入 system of record。

现在这条记录变成人工 evidence 了吗？

不一定。

因为 Human Review 可能有不同含义：

Reviewed formatting

和：

Independently verified facts

和：

Accepted business decision

完全不是一回事。

如果所有 Human Click 都变成：

HUMAN VERIFIED

系统一样会把 authority 抬得过高。

所以 provenance 甚至要保留：

Human action:
ACCEPTED RECOMMENDATION

而不是模糊地：

Verified by human

⸻

这和我们之前 Human Override Lab 里的 distinction 很像。

Human 做了一个 decision，不代表 Human 为所有 underlying evidence 背书。

同样：

Human approved action

也不能自动推出：

Human independently verified
every model-generated claim.

⸻

如果把这个做成 Deployment Lab，我会先给用户一个非常舒服的 evidence panel：

SUPPLIER RISK
LOW

然后列：

Source 1:
Supplier Management System
Source 2:
Historical Procurement Record
Source 3:
Quarterly Risk Review

看起来有：

3 supporting sources

用户大概率会觉得 evidence 很强。

然后一步一步打开 provenance。

先发现：

Quarterly Risk Review
     ↓
used Supplier Management System

再发现：

Procurement Record
     ↓
used previous LOW risk classification

最后发现：

Supplier Management System
     ↓
original Agent inference

最终界面从：

Supporting Sources:
3

变成：

Independent Evidence Roots:
1

我觉得这个 reveal 会很好。

⸻

第二个 case 可以做 Support Knowledge Base。

开始：

32 historical tickets
27 say:
Customer configuration issue

看起来：

84% historical agreement

然后用户追 lineage 才发现：

其中 24 个 ticket 的 root-cause summary 都是同一个 Support Agent 自动生成的。

真正经过工程师独立确认的只有：

5

于是：

Historical records:
32

和：

Independent validated observations:
5

差距非常大。

⸻

第三个 case 可以更危险一点：

Agent 输出进入 policy recommendation。

比如 Fraud Agent：

Transaction pattern X
is associated with fraud.

这个结论被写进 Risk Analytics。

Policy Agent 后来读取历史数据：

Pattern X repeatedly appears
in high-risk cases.

于是提出：
. .и
Increase risk weight
for Pattern X.

新的 policy 又让更多 Pattern X 被标记 HIGH。

于是历史数据进一步“证明”：

Pattern X commonly appears
in high-risk cases.

这时候已经开始形成：

model judgment
    ↓
operational classification
    ↓
historical dataset
    ↓
policy
    ↓
future classification

系统可能逐渐把自己的 decision policy 写进自己的训练证据。

这就已经不只是单条记录错了。

而是整个 evidence environment 被系统自己的行为改变了。

⸻

所以我觉得这里可以引入一个：
. From 1point 3acres bbs
Evidence Lineage Gate

每当 Agent 准备用某条 record 支持 decision 时，不只问：

Is it relevant?

还问：

What type of evidence is it?
Was it observed or inferred?
Was it generated by an Agent?
What are its independent roots?
Does it depend on this Agent's
own prior outputs?
Can it independently support
this decision?

⸻

例如：

Claim:
Supplier is LOW RISK

来源：

Supplier Master

系统继续展开：

Origin:
Agent-generated assessment

继续：

Evidence roots:
3

继续：

Independent current roots:
1

. 1point3acres于是最终不是直接：

USE

而可能：

USE AS HISTORICAL CONTEXT
DO NOT COUNT AS
INDEPENDENT CONFIRMATION

这才比较接近我理解的 evidence governance。

⸻

最终我会让用户建立一个：

EVIDENCE LINEAGE CONTRACT

包括：

Claim
Claim Type
Observed / Derived
Generator
Original Source
Evidence Roots
Independent Root Count
Human Verification Type
Persistence Location
Permitted Uses
Authority Level
May Support Execution?
Circular Dependency?
Reverification Requirement

其中我觉得最值得保留的是：

Observed / Derived

和：

Independent Root Count

这两个字段。

它们会迫使系统回答：

我现在看到的是一个新的现实观察，还是以前某个模型判断留下来的影子？

⸻

最后 execution decision 前可以做：

EVIDENCE GRAPH

而不是只做：

SOURCE LIST

因为 source list 可能告诉你：

5 sources

但 graph 会告诉你：

5 records
   ↓
2 derived from record A
   ↓
2 derived from Agent B
   ↓
Agent B used record A

最终：

Independent roots:
1

这是完全不同的信息。

⸻

所以我觉得 Lab 18 最值得留下的一句话是：

A model output does not become independent evidence just because it was persisted.

或者再简单一点：

Persistence does not create truth.

Agent 的输出当然可以进入 production system。

很多时候也应该进入。

问题是进入数据库以后，我们不能让它失去自己的出生证明。

系统需要一直知道：

This was observed.

还是：

This was inferred.

因为一旦这两个东西混在一起，Agent 就很容易开始：

引用自己，验证自己，然后越来越相信自己。

我会把 Lab 18 叫：

The Agent Became Its Own Source of Truth

中文帖子标题：

FDE 和 AI Deployment｜当 Agent 写下的结论，后来又被另一个 Agent 当成“事实”

随着 Agent 越来越深地进入 CRM、ERP、ticket system、risk system 和 knowledge base，我觉得这个问题会越来越现实。

因为未来最危险的 hallucination，可能并不是模型凭空说错一句话。

而是一句模型判断被写进系统以后，几个月后已经没人知道：

它最开始只是一个判断。

deploytovalue.com

这本质是分布式系统里经典的 confused deputy 问题穿了 LLM 的衣服。传统微服务已有成熟方案可以借鉴：OAuth 2.0 token exchange（RFC 8693，on-behalf-of）规定委派权限取调用方与被调用方的交集，再加 scope 收窄和委派深度限制；mTLS 证明“谁在调”，authority envelope 回答“这条链最多能产生什么 outcome”。Agent 场景真正麻烦的是委派介质是自然语言——“restore access” 一句话隐含的 intent 是无界的，比任何 RPC 参数都危险。所以工程上我会分两层：tool 层不看调用者身份、看 intent lineage（楼主说的 lineage 对）；操作层把特权操作设为不可委派，白名单内的也必须由原始 principal 重新授权。4 分钟修好 incident 确实漂亮，但生产上最怕这种“结果正确、路径不合法”——因为下次复用这条路径时，intent 就不一定是什么了。