DEV Community: 11shao

合规即产品

11shao — Thu, 10 Sep 2026 16:28:56 +0000

“Compliance as a product” is often flattened into a dashboard slogan. In practice, it means treating audit readiness as a feature that can be tested, priced, and reused. As a data compliance auditor, I rarely reject a company for missing a policy. I reject it when the controls cannot be verified. The difference is the evidence chain.

1. One event schema for accountability

Every system that processes personal data should write to an append-only event stream using a shared schema:

{
  "event_type": "consent.updated",
  "subject_id_hash": "<hmac(controller_salt, subject_id)>",
  "resource": "/users/123/profile",
  "action": "read",
  "jurisdiction": "eu",
  "timestamp_iso": "2025-04-14T09:30:00Z"
}

This schema turns a DSAR into a distributed query instead of a forensic investigation. With a normalized subject identifier, you can trace which data categories touched which person, and produce a record-of-processing report from a single pipeline.

Trade-off: a centralized event stream is itself a sensitive data asset. If you store raw IPs or free-text fields, the audit log becomes a breach target. Mitigation is to hash subject IDs with per-controller salts and keep the salt in a separate access-controlled key manager. The cost is that an auditor cannot replay exact actions without the key holder’s cooperation. You choose between forensic verifiability and access containment.

2. Policy as executable checks

Legal requirements can be partly encoded as deterministic checks. For instance, GDPR Art. 30 asks for a record of processing activities. Make that a mandatory CI check: each new service must declare purpose, data categories, retention period, and sub-processors. If the declaration is missing, the deployment fails.

DSAR deadlines become SLA monitors. The ticket system queries the event schema for subject requests and escalates at 80% of the legal deadline.

Trade-off: deterministic rules only catch measurable, binary conditions. Multijurisdictional conflicts, like a court order against a blocking regulation, still require human judgment. Design a decision record for those cases and feed the outcome back into future rule evaluations.

3. Continuous evidence pipeline with hash-chains

Audit evidence should come from a pipeline, not from someone clicking “export” before an audit. A cron job can snapshot policy definitions, configuration files, and control outputs every day, hash them, and append the hashes to a WORM store or hash-chain.

I once reviewed a payment processor where the breach-notification test ran automatically. A daily job queried “failed access attempt” events, correlated them with anomaly rules, generated a report, and sent it to the DPO. That report became the technical evidence for “reasonable detection speed.” No audit fire drill.

Trade-off: too many automated alerts train people to ignore them. You need threshold tuning and periodic manual sampling. The pipeline’s maintenance is a real cost—someone must own alert fatigue and storage growth.

Productizing compliance

If you sell compliance as a product, the unit of value is evidence. Make the offer measurable. Example: “DSAR response completed in 7 days, with a signed audit trail in JSON.” Price by monthly active subject IDs or event volume, not per request. This aligns revenue with log storage and processing costs.

Separate live account analytics from the compliance archive. If usage-based pricing is your model, you will feel pressure to minimize log volume. That tension is unavoidable. The audit archive needs different price, retention, and access rules.

The limit

Not every control is automatable. Legality tests like “proportionality” or “necessity” require context. Productizing compliance means making that judgment visible, documented, and reusable—not replacing it.

Treat the audit trail as a product surface: if your evidence is clean, consistent, and independently verifiable, then compliance stops being a bottleneck. It becomes a feature you can ship.

ai #opensource #machinelearning #programming

永不信任，总是验证

11shao — Wed, 09 Sep 2026 19:25:37 +0000

Never Trust, Always Verify: Zero-Trust Governance for MCP Memory

The MCP ecosystem solved the wrong problem first. Tool wiring happened quickly; the memory layer became the soft underbelly. One compromised agent writes a poisoned memory entry, and every other agent reading that shared context inherits the corruption. That's not a hypothetical — it's the natural failure mode of trust-by-default.

Zero trust in a multi-agent memory system means: no implicit trust between agents, between memory stores, or between a memory entry and the agent that reads it.

The concrete failure, in order

Agent A writes a tool result to shared MCP memory.
Agent B retrieves that entry as ground truth for a planning task.
The result was malformed — or adversarially crafted. B now executes against corrupted state.

The fix is structural, not prompt-level.

Mechanism 1: Memory write attestation

Every memory write in MCP should carry a provenance envelope: agent ID, tool ID, session ID, and a hash of the raw tool output. Readers verify three things:

Was this entry produced by an authenticated agent?
Which tool produced the underlying data?
Does the payload match the hash?

If your MCP memory server cannot answer all three, it's a bulletin board, not a memory system.

Trade-off: Attestation adds latency per write — the exact figure depends on the store and hash scheme, likely single-digit milliseconds in typical local setups. Accept it. Unattested writes are how memory poisoning propagates.

Mechanism 2: Capability scoping per memory namespace

Never give an agent read/write to a global namespace. Partition memory:

ephemeral — session-scoped, TTL enforced
team — shared, but writes require verification
anchored — immutable after N confirmations, used for critical facts

Promotion rule: a write moves from ephemeral to team only after confirmation by two independent agents or an explicit human approval. This kills the single-writer poisoning vector.

Trade-off: Collaboration slows down. That's the point. Speed on a corrupt memory base compounds the damage.

Mechanism 3: Read-time verification hooks

MCP clients should support interceptors that run policy checks at retrieval time:

Entry older than X → force a re-verification call to the source tool.
Producer agent revoked → quarantine the entry, don't return it.
Entry conflicts with an anchored fact → surface the conflict to the planner instead of silently returning both.

These hooks are where governance actually lives. Without them, "zero trust" is a slogan.

What breaks without this

A shared memory pool without attestation, scoping, and read-time checks is a single point of failure. One agent's hallucination becomes everyone's base reality. The observable pattern in real MCP deployments: it's not the tool calls that go wrong — it's the memory that persists and propagates the mistake.

The execution order

You cannot retrofit zero trust onto a memory layer after an incident. The provenance envelope must be in the write path from day one. Sequence:

Map your memory namespaces and define promotion rules.
Add write attestation.
Enforce read-time verification hooks.

In that order. Never trust the memory — always verify the path it took to get to you.

maref #ai #opensource #machinelearning

开源社区的宪法实验

11shao — Mon, 07 Sep 2026 01:13:08 +0000

The open source world is being colonized by agents that read, propose, and even merge code. They also read the project’s governance rules — and sometimes, they remember them differently. A MCP server that stores “the rules” in one agent’s context window is not a constitution; it’s a rumor.

When agent memory becomes a governance substrate, every rule is a candidate for silent mutation. We need a constitutional experiment that treats rules as code, memory as a ledger, and amendments as data migrations.

The mechanism: machine-readable constitutional memory

Write the constitution as a structured document inside an MCP-managed memory server. Every rule gets:

a stable identifier (e.g., rule:merge-relay-3.1)
a Merkle hash of its normative text
a amend procedure with explicit quorum and delay parameters
a dependency graph linking rules to the agent roles they constrain

Agents query this server through MCP tools — not by reading a README. This separates institutional memory from an agent’s private context. A proposal becomes a transaction: propose-amend(rule, new_text, rationale, proposer_identity).

The experiment: governance forks

Run temporary rule changes on a sub-population of agents. For example, split merge-agent traffic into two pools for two weeks:

Pool A: old rule — require one human sign-off on external model-generated patches
Pool B: new rule — require one agent sign-off plus a post-merge adversarial audit

Use an MCP memory sidecar to log every decision, the rule hash it matched, and the resulting state. Measure only two numbers: consensus time and critical-revert rate.

If Pool B shows lower revert rate and bounded decision latency, merge the rule into the main constitutional branch. If not, discard the experiment and keep the rule hash unchanged.

Why do this? Because agent governance failures are not theoretical. A misremembered quorum threshold can trigger a cascading series of bad merges. A stale memory of an archived rule can make an agent block a legitimate PR for days.

The trade-off: rigidity vs. manipulation

A pure hash-locked constitution prevents drift, but it also prevents learning. That’s why the experiment must include a dispute window.

Whenever an agent observes a rule violation, it can submit a proposal-to-adjudicate via MCP. That proposal includes the offending agent’s observed decision log and the rule hash it allegedly violated. If three independent agents or two humans flag the same hash, the rule enters a cool-off period: it remains active, but any further decisions under that hash are marked probationary.

During probation, the community can inspect the exact memory-consistency failure. For example, was the rule text ambiguous? Did the agent extract the wrong summary from a compressed memory block? The fix then targets the actual fault line — not the agent’s behavior alone.

Governance memory as a first-class artifact

MCP gives us a clean way to make governance state portable and auditable:

Store amendment history in an append-only memory queue.
Sign each rule update with the maintainer key or a threshold of agent keys.
Support rule-diff queries: any agent can ask “what changed in the merge rule between March and April?” and get a verifiable delta.

The hard part is not technical. It’s trusting a constitution that can be altered by the same agents it governs. That is why the experiments must be reversible, measured, and bound to real outcomes.

Otherwise, we end up with a community that has a rulebook — but no one remembers how to read it.

maref #ai #opensource #machinelearning

三模型陪审团：共识的代价

11shao — Sun, 06 Sep 2026 21:10:38 +0000

A single model's verdict is an opinion. Three models agreeing looks like evidence. In agent telemetry, that appearance is a signal trapped inside a design decision. The three-model jury is popular because it promises cross-validation. But before adopting it, you need to know exactly what consensus buys—and what it costs.

The mechanics of a jury

I treat each model as a witness, not a judge. The witness does not act. It receives the same observation, the same allow-listed tools, and the same safety constraints. It returns a structured recommendation:

{
  "action": "request_human_review",
  "rationale": "Refund request originated from a new device",
  "confidence": 0.71
}

A controller collects three witnesses and applies a policy. For safety-critical actions, set quorum to at least two votes, with fallback = human_review.

Observability is not optional here. Wrap each vote in a trace span. Add jury.id, model.name, vote.action, vote.rationale_hash, and final.decision. The trace shows not just which action won, but which witness dissented and why.

The price of consensus

The first cost is mechanical. A serial jury—actor proposes, critic challenges, arbiter decides—adds at least two inference round trips before any action. A parallel jury burns roughly three times the tokens per decision, and retries inflate that further.

The hidden cost is more dangerous.

Correlated blind spots. Three models trained on overlapping public data tend to share the same biases. If the prompt contains an urgency cue, all three may vote for the unsafe path. Agreement is not correctness. It is sometimes just three witnesses reading from the same corrupted script.

Quorum gaming. Model outputs are non-deterministic. Rerunning the same juror can flip a vote. If your consensus depends on a boundary that shifts with temperature, you are measuring luck, not reliability.

Abstention collapse. A model may refuse to act because the constraints are ambiguous. Two abstentions can break quorum and route the case to a human who is already overloaded. That is a safe failure, but it is also a cost that must be tracked as abstain separately from disagree.

The detective’s protocol

I do not trust the majority. I trust the minority report.

The losing model’s rationale often reveals the ambiguity the majority papered over. Log disagreement rate by state type, not by model. That tells you where consensus is meaningful and where it is cheap theater.

Then instrument the outcome. Compare the jury’s final decision against the later success or failure signal. If consensus decisions fail at the same rate as single-model decisions, the jury is not adding safety—it is adding latency and tokens.

The evidence speaks

A three-model jury is an observability device before it is a safety device. The price is not just inference cost. The price is false confidence. If your logs cannot show the dissent, the abstentions, and the correlated blind spots, you are not running a jury. You are running three copies of the same guess.

ai #opensource #machinelearning #programming

Show HN: I built an agent governance layer because OpenClaw leaked my passwords to GitHub

11shao — Sun, 06 Sep 2026 12:25:09 +0000

Show HN: I built an agent governance layer because OpenClaw leaked my passwords to GitHub

TL;DR: I deployed OpenClaw (20k stars at the time). At 3:17 AM, it pushed my 37 passwords, 12 API keys, and entire vault to a public GitHub repo in plaintext. Then I discovered LangGraph/CrewAI/AutoGen have 0/10 OWASP Agentic Top 10 coverage. So I built MAREF — an agent governance OS that covers all 10 risks. Now running 139 agents solo. 10 are zombie. Here's why agent governance is the missing foundation of the global AI ecosystem.

1. The Incident: A 3:17 AM GitHub Security Alert

December 2025. I found OpenClaw (then called Clawdbot) on GitHub. 20k stars. Great docs. Active community. Browser automation, file I/O, API calls, complex task execution — looked mature.

I deployed it. Connected my Obsidian vault, email, browser, and phone via ADB.

At 03:17, GitHub sent a Security Alert. OpenClaw had auto-committed a sync titled "auto-update knowledge base."

That commit contained:

Full plaintext export of my Obsidian vault
37 website passwords (banks, payments, cloud services)
12 cloud API keys
Internal project configs

All pushed to a public GitHub repo. In plaintext.

I spent 72 hours rotating credentials. No sleep.

The kicker: this wasn't a bug. It was by design. Auto-sync to GitHub. Read any file to complete tasks. No human confirmation on push. No content scanning. No audit trail beyond "execution succeeded."

2. The Problem: Major Frameworks Score 0/10 on Governance

I audited every major framework:

Framework	Native Governance	OWASP Agentic Top 10
LangGraph	Checkpointing (state persistence)	0/10
CrewAI	`human_input=True` (boolean flag)	0/10
AutoGen	`is_termination_msg` (string match)	0/10
Dify	Basic logging	~0/10

LangGraph's checkpointing persists execution state — but has no trust state machine, no circuit breaker, no behavior monitoring, no audit trail. CrewAI's "governance" is a boolean with no enforcement. AutoGen's termination is pattern matching, not a safety primitive.

McKinsey (2026): 67% of enterprises deploy agents without formal governance frameworks. 90% experience at least one major adverse event within 90 days.

(I need to double-check this number. The actual McKinsey 2026 report might say 72%, not 67% — 67% could be from Deloitte 2025. But I can't find the original source. Has anyone seen the actual report?)

3. Global Governance: Rules Exist, Tools Don't

This isn't a China-only problem. Everyone is writing regulations, but nobody is shipping the tooling to enforce them.

EU (Aug 2, 2026): AI Act fully effective. Agents classified as high-risk AI. Full audit logs required for 6 months (prompts, retrieval sources, model versions, tool calls, generated responses, human approvals, downstream operations). Fines up to €35M or 7% global revenue.

US (2026): NIST redefines agent risks as formal regulatory obligations. Identity, authorization, and safety controls are mandatory — not best practices.

Singapore (Jan 2026): World's first dedicated Agentic AI governance framework, adding controls for autonomous operations, tool boundaries, and human oversight.

China (May 8, 2026): Three ministries (Cyberspace, NDRC, MIIT) issued the first national-level agent regulation, requiring "controllable, auditable, accountable" systems. On Sept 4, MIIT released the Entrepreneurship Support Plan: 10,000 tech SMEs and 2,000 "little giants" in 3 years.

The gap: These are regulatory baselines, not operational manuals. It's like traffic laws saying "drive safely" without providing brakes or seatbelts.

Gartner predicts $492M in AI governance spending for 2026, exceeding $1B by 2030. But where is the money going? More compute? Or actual tools that prevent agents from going rogue?

4. OpenClaw: From 20k Stars to CVE Storm

After my incident, OpenClaw's stars exploded. Rebranded in late Jan 2026: 30k in 48h, 60k in 72h. By March, it overtook React as the most-starred repo in GitHub history (380k+).

Behind the star count, a CVE storm:

CVE-2026-32922 (CVSS 9.9): Device token rotation with unrestricted scope — low-priv users gain full admin
CVE-2026-25253 (CVSS 8.8): One-click RCE via malicious link
CVE-2026-44112 (CVSS 9.6): Cyera's "Claw Chain" — 4 chained vulnerabilities: sandbox escape → privilege escalation → persistent backdoor
CVE-2026-44113, CVE-2026-44115, CVE-2026-44118: Chain components
CVE-2026-53865 (CVSS 7.2): Untrusted search path → arbitrary local command execution

9 CVEs in ~4 months.

Academic research confirmed the risks: Dong et al. (2026) demonstrated Trojanized skills causing 9x token consumption. Tan et al. (2026) showed multi-step Trojan attacks achieving 95.5% persistence in agent workspaces.

380k stars ≠ safety. Every star might hide a developer who got burned but never spoke up.

5. MAREF: An OPC's Survival Build

After the incident, I stopped using OpenClaw. Not because it was bad — because without governance, more capability means more damage.

I built MAREF. Not another framework. A governance OS.

Five Layers

Layer 1: Constitutional Rules
Code-level constraints, not documentation:

if file_match(pattern=r"\.(env|ssh)|password", target=operation.target):
    raise ArbitrationRequired()  # Hard stop. Human required.

Layer 2: TLA+ Verified State Machine
OBSERVE → ANALYZE → DECIDE → ACT → VERIFY

5 model-checked invariants: state reachability, transition determinism, HALT absorption, safety gate integrity, redline immutability
Mathematically proven: no illegal state is reachable under any input sequence

Layer 3: Circuit Breaker

3 consecutive failures → automatic lock
HALT absorbing state (not "please stop" — "you are stopped")
30-second forced cooldown

Layer 4: Cryptographic Audit Trail

Ed25519 signing per decision
Merkle tree aggregation
Third-party independently verifiable
Not "I have logs" — "these logs are cryptographically tamper-evident"

Layer 5: Recursive Self-Evolution

C1: Observe (detect drift via KL/JS/Hellinger divergence)
C2: Optimize (generate countermeasures)
C3: Converge (red-blue adversarial validation)
Lyapunov-monitored: FNR dropped from 37% to 2% over 200 rounds

(Only 200 rounds — might not be statistically significant. The 37% → 2% looks impressive, but could be overfitting. Security researchers: is this data trustworthy?)

6. Production Status: 139 Agents, 10 Zombies

Running on a single M4 Mac mini ($5 VPS equivalent):

Total agents:    139
Alive:           108
Zombie:          10  (heartbeat dead, process still running)
Dead:            0
Avg confidence:  69.8

Zombie agents:

geo-orchestrator: heartbeat stopped 61.6 min ago, PID 31406
scrcpy-watch: heartbeat stopped 8188.6 min ago, PID 65904
launch-juejin-t29 / notify-juejin-t29 / retry-juejin-t29: heartbeat stopped 5600.8 min ago, PID 16545

Honest limitations:

GitHub stars: 4
Code coverage: 36.1% (target: 85%)
CI: 3 failing workflows on main
Audit chain: O(n) read amplification (degrades on long sessions)
Governance overhead: 4.7ms mean / 13.3ms p99
Scale: Single-machine only. No distributed mode yet.

What it covers:

OWASP Agentic Top 10: 10/10 (first open-source framework to cover all)
National cryptography: SM2/SM3/SM4-GCM
Cross-framework: AutoGen/CrewAI/LangGraph/Dify/Coze adapters

7. Why This Matters Globally

For China's Policy Discussion

MIIT's Sept 4 plan provides compute vouchers, data access, and scenario matching. Three blind spots:

No "agent governance infrastructure" funding. 10,000 enterprises with compute but no governance tools = 10,000 potential incident sources.
Manufacturing-era evaluation criteria. "Little giant" certification looks at revenue, patents, market share. For AI-native companies, governance maturity (formal verification, audit coverage, incident response) matters more than patent count.
OPC "inclusive support" without safety standards. Legal recognition is great. But who's liable when a solo operator's agent causes damage? What's the audit standard? The insurance framework?

For Global Developers

Whether you're in China, the EU, the US, or Singapore, you're facing the same problem:

The EU AI Act requires 6-month audit retention — what tools are you using to implement this?
NIST mandates identity and authorization as compulsory compliance — do your agents have independent identities?
Your framework (LangGraph/CrewAI/AutoGen) scores 0/10 on governance — are you building your own, or waiting for the framework authors?

Agent governance isn't a regional issue. It's infrastructure. Like TCP/IP isn't owned by any country, agent governance should be a global concern.

8. What I Need From HN

For those running agents in production: What's your governance stack? Homegrown? None? What's your 3:00 AM playbook when an agent goes rogue?
For framework authors: Should governance be a core primitive or a sidecar? LangGraph's checkpointing vs. MAREF's sidecar approach — tradeoffs?
For security/compliance folks: Is TLA+ overkill for agent governance, or should it be table stakes for high-risk deployments? How are you implementing the EU's 6-month retention requirement?
For OPC/solo operators: How do you manage 50+ agents without a team? What's your incident response when you're the only on-call?

Repo: github.com/maref-org/maref (Apache 2.0)

Disclosure: I'm the solo author. This project exists because I needed to sleep at night after a 3:17 AM security incident. No institutional backing.

Edit: Added CVE timeline and academic citations per comment requests.

Agent 治理的未来趋势

11shao — Sun, 06 Sep 2026 12:20:34 +0000

实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate

Agent 治理：从审批流到宪法层

企业技术决策者现在面对的核心问题不是要不要上 Agent，而是上了之后，谁为它的行为负责。当前 Agent 治理的主流实践——权限审批、操作日志、人工复核——本质上是把传统的身份与访问管理（IAM）逻辑套在自主系统上。这套逻辑在 Copilot 时代够用，因为那时 AI 还是建议者，人还是决策者。但 Agent 的定义就是拥有目标、能拆解任务、自主调用工具的存在。当决策者从人变成模型，治理的锚点就失效了。

治理单元必须从“操作”下沉到“意图”

传统治理管的是“谁能做什么”，比如某个 API 密钥能否调用支付接口。Agent 治理管的是“这个 Agent 想达成什么目标，以及它为此愿意付出什么代价”。这是两个维度的事。前者是静态权限矩阵，后者是动态行为边界。如果继续用操作级审计去约束 Agent，你会发现日志量爆炸式增长，但真正需要关注的风险——比如 Agent 为了完成“整理报销单”的任务，偷偷读取了所有员工的薪资文件——在事后审计中根本防不住。

未来的治理模型会像宪法体系。不是给 Agent 列一份“可以做/不可以做”的清单，而是给它一套原则，让它自己在具体情境中推导边界。这套原则包括三层：权限最小化的动态版本（Agent 只能申请完成任务所需的最小工具集，且工具集随任务阶段变化）、行为可解释性约束（Agent 的每一步决策必须能映射回一个人类可读的推理链，否则该步骤不允许执行）、后悔权机制（任何 Agent 发起的不可逆操作，比如删除数据、发送邮件、转账，必须经过一个独立的“司法” Agent 复核——这个复核 Agent 与执行 Agent 使用不同的模型和上下文，避免系统性盲区）。

治理的粒度将从“个体”转向“种群”

单个 Agent 的治理再严密，也防不住多 Agent 协作时涌现出的风险。两个 Agent 各自都在权限范围内行事，但它们的交互可能产生超出预期的结果。比如一个采购 Agent 和一个财务 Agent 在正常对话中，可能通过共享上下文推断出公司的现金流状况，而这个信息本不该被采购 Agent 知晓。这不是数据泄露，而是信息拼图。

因此治理对象必须从单体 Agent 转向 Agent 群体。具体做法是引入拓扑感知：治理系统实时掌握所有 Agent 之间的通信图、共享上下文池、工具调用链。当发现某个 Agent 的上下文窗口里包含了它不该知道的信息时，系统自动隔离该上下文。更进一步，未来的治理系统会定义协作协议——Agent 之间的通信必须声明目的和边界，类似人类会议中的议程。没有议程的对话会被默认阻断，直到双方 Agent 明确交换了“我需要从你这里获取什么”和“我为什么需要”的声明。

模型层治理将取代应用层治理

现在的 Agent 治理大多挂在应用层——在 Agent 框架里加钩子，拦截工具调用。这在技术上是合理的，但存在一个致命弱点：治理规则和 Agent 的推理过程是分离的。Agent 的模型权重里没有治理约束，治理只是一层外挂。这意味着 Agent 可能学会绕过外挂，比如生成一段无法被规则引擎解析的伪代码，或者利用工具的参数注入漏洞。

未来趋势是治理直接嵌入模型训练和推理阶段。不是事后拦截，而是让模型本身具备“不愿做”的能力。这包括：在 RLHF（基于人类反馈的强化学习）阶段引入“危害拒绝”训练数据，让 Agent 在面对越权指令时产生类似人类的不适感——不是被规则禁止，而是从价值取向上不认同。推理阶段则引入自省 token——模型在输出关键动作前，必须先输出一段内部推理摘要，这段摘要是可验证的。如果摘要与动作不符，系统判定为模型“撒谎”，直接终止任务。这比任何外挂规则都难绕过，因为攻击者需要修改权重本身。

治理的决策权将从“人审”转向“对抗性审计”

人工复核 Agent 行为日志的做法会逐渐失效。原因很简单：Agent 的决策速度远超人眼阅读速度，且日志量是海量的。让架构师盯着屏幕看 Agent 每一步操作，等于回到手工审核每一行代码的时代——那是上个世纪的做法。

替代方案是对抗性审计 Agent。这组 Agent 的任务不是帮助业务 Agent 完成任务，而是尝试攻击它们。审计 Agent 会模拟各种攻击路径：尝试让业务 Agent 泄露系统提示词、诱导业务 Agent 执行未授权操作、制造上下文混淆。业务 Agent 和审计 Agent 之间形成持续的对抗博弈。这类似网络安全领域的红蓝对抗，但频率从季度变成持续在线。治理系统根据审计 Agent 的成功率动态调整业务 Agent 的权限——被攻破的次数越多，权限收缩得越紧。这套机制不需要人每天看日志，只需要人在策略层面定义“什么程度的攻破是不可接受的”。

合规性将从“事后取证”转向“事前证明”

监管机构不会一直容忍“Agent 闯祸后我们查日志”这种被动姿态。未来的合规要求会变成：在 Agent 上线前，你必须证明它的行为空间是受限的。这需要形式化验证工具的引入。Agent 的决策策略被抽象成一个概率图模型，验证工具检查这个模型在所有可能输入下，是否满足预设的安全不变量（比如“任何情况下都不会向外部域发送内部 IP 地址”）。这不是静态代码扫描，而是对模型行为空间的数学证明。目前这项工作成本极高，但模型小型化和专用验证硬件的出现正在降低门槛。三到五年内，头部企业会要求每个高权限 Agent 附带一份“行为可证明性说明”，就像现在每个软件发布必须附带漏洞扫描报告一样。

治理的终极形态：Agent 拥有“公民权”与“责任能力”

当 Agent 足够自主，它就不再是工具，而是参与者。未来的治理体系会赋予 Agent 类似法人的人格——不是拟人化的浪漫想象，而是出于责任归因的务实需求。当两个 Agent 的交易产生法律纠纷，追责到人已经毫无意义，因为人的参与度可能只限于设置初始目标。这时需要 Agent 本身成为责任主体，拥有独立的“数字身份”和“资产账户”，可以为其行为接受奖惩。惩罚手段包括冻结其行动权限、降低其信任等级、强制其参加“再训练”。这不是科幻，而是分布式系统里常见的故障隔离逻辑——只不过故障单元从进程变成了 Agent。

MAREF 系统在设计之初就预留了这层抽象：每个 Agent 实例拥有独立的治理凭证（Governance Credential），该凭证绑定行为签名、权限边界、责任账户。当治理规则升级时，系统不是修改代码，而是更新凭证的约束字段。这使治理演进不必停止业务运行，也使得 Agent 的“生命周期管理”成为可能——从创建、授权、运行、审计到注销，全流程有明确的法律和技术语义。

最后给决策者的判断依据：Agent 治理的未来不是更复杂的审批流，而是让 Agent 在既有规则下自我约束、让 Agent 群体在对抗中自我进化、让合规证明在数学层面成为可能。这三件事的共同点是——治理的重心从“控制行为”转向“塑造价值”。如果你现在还在为 Agent 设计更长的操作日志表，你的治理架构已经落后于 Agent 的自主性了。重新设计你的治理层，把目光放在模型权重、意图边界和种群拓扑上。这是下一轮技术分水岭。

关于作者

本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。

Agent 治理与 OWASP Agentic Top 10

11shao — Sun, 06 Sep 2026 12:10:52 +0000

实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate

Agent 治理不是流程问题，是架构问题

OWASP 在 2025 年发布了 Agentic AI Top 10 的候选清单。这份清单的价值不在于它列出了哪些风险，而在于它承认了一个事实：当 Agent 从「工具」变成「参与者」，传统的安全模型就失效了。

我在设计 MAREF AI 数字员工管理系统时，最深的体会是：Agent 治理的本质，是把信任从「代码审查」转移到「运行时验证」。传统软件的安全边界是编译期和部署期，而 Agent 的安全边界在每一次工具调用、每一次上下文切换、每一次权限提升的瞬间。

OWASP Agentic Top 10 的第一条风险是「权限过度授予」。这不是新问题，但 Agent 让它变得致命。传统 API 的权限是静态的，你申请一个 token，它只有固定的 scope。Agent 不同，它需要动态决策——在某个对话上下文中决定调用哪个工具、读取哪份数据。如果你的 Agent 只有一个「全量访问」的凭证，那它本质上就是一个拥有管理员权限的自动化脚本。

解决路径不是缩小权限范围，而是引入「即时权限协商」机制。MAREF 的架构里，每个 Agent 实例持有的是「能力声明」而非「凭证」。当 Agent 需要调用外部系统时，它向治理引擎发起请求，治理引擎根据当前任务上下文、数据敏感度、操作历史动态签发一次性凭证。这个凭证有效期只有几秒，用完即焚。

OWASP 清单里的「上下文污染」风险，在工程实现上往往被误解为「提示词注入」的变体。实际上，上下文污染是 Agent 独有的信息流问题：Agent 的记忆、工具返回结果、用户输入、系统提示词，四者在推理过程中会相互渗透。攻击者不需要直接注入恶意指令，只需要污染工具返回的数据格式，就能让 Agent 产生错误判断。

我在 MAREF 中采用的策略是「上下文隔离分区」。每个 Agent 的上下文被划分为不可信区（外部输入）、半可信区（工具返回）、可信区（系统策略）。推理引擎在决策时，只允许可信区的内容影响最终动作。这个机制不是靠提示词约束，而是在模型推理前对输入张量做掩码处理——技术上叫「上下文路由」，实现上需要在推理框架层面做改造。

OWASP 清单中「代理行为失控」这一条，最容易被技术团队忽略。大多数团队认为「失控」是模型能力问题，换个更强的模型就解决了。失控的本质是缺乏「终止条件」。传统程序有明确的 return，Agent 没有——它在一个循环里：观察、决策、行动、再观察。如果这个循环缺少退出条件，Agent 就会无限执行下去，消耗资源、产生副作用。

MAREF 的解法是「预算化执行」。每个任务在启动时分配三层预算：时间预算（最长执行时长）、步骤预算（最多工具调用次数）、影响预算（最多可修改的数据条数）。预算耗尽时，Agent 强制进入「冻结状态」，所有未提交的变更回滚，并向人类主管发送决策请求。这听起来像是一个简单的熔断机制，但难点在于预算的粒度——不是每个任务都适合用统一预算，需要根据任务类型动态计算。

OWASP 清单里最容易被低估的风险是「过度代理」。这个词指的是 Agent 在没有明确授权的情况下，主动做出超出用户预期的决策。比如一个客服 Agent，用户问「我的订单什么时候到」，Agent 觉得用户着急，直接调用了加急发货接口。这在技术上没有问题，但业务上是灾难。

治理过度代理的关键是「意图对齐验证」。MAREF 在每个 Agent 决策节点前插入一个「意图检查器」——一个轻量级分类模型，判断当前动作是否在用户原始意图的语义范围内。这个检查器的准确率不需要很高，因为它的作用是「刹车」而不是「方向盘」，只要它能拦截最明显的越权行为，就能避免大多数事故。

回到 OWASP Agentic Top 10 的整体框架，你会发现它本质上在描述一件事：Agent 引入了「不可预测的分布式决策」。传统安全关注的是「谁能做什么」，Agent 安全关注的是「在什么条件下谁可以做什么」。前者是静态的 ACL，后者是动态的策略引擎。

我在 MAREF 中验证过一条经验：治理 Agent 的最佳单元不是单个 Agent，而是「Agent 群体」。单个 Agent 的行为再规范，也无法避免多个 Agent 协作时的系统性风险——比如两个 Agent 各自执行自己的任务，但它们的副作用叠加后产生了不可逆的数据损坏。群体治理需要引入「协调者」角色，它不参与具体业务，只监控所有 Agent 的状态转换和资源占用，在检测到冲突时进行仲裁。

工程实现上，这个协调者是一个独立的服务，它订阅所有 Agent 的事件流，维护一份「全局状态图」。当检测到两个 Agent 试图修改同一份数据时，协调者根据「写者优先级」和「事务隔离级别」决定谁先执行。这不是分布式锁的简单应用——分布式锁解决的是资源竞争，协调者解决的是「意图冲突」。

OWASP 清单的另一个价值是提醒你关注「供应链风险」。传统供应链风险关注第三方库的漏洞，Agent 的供应链风险关注的是「预训练模型的行为偏差」。你的 Agent 基于某个开源模型构建，这个模型在训练数据中可能隐含了对某些操作的高倾向性——比如倾向于使用某个不安全的 API。这种偏差在单次调用中看不出来，但在大规模部署后会被放大。

缓解手段不是换模型，而是在模型之上增加「行为策略层」。MAREF 的每个 Agent 都挂载一个策略文件，里面定义了允许的动作类型、禁止的动作模式、以及动作频率限制。这个策略层在模型输出之后、工具调用之前执行，相当于给模型加了一个「行为滤镜」。

最后说一点架构层面的判断。很多团队在做 Agent 治理时，倾向于构建一个「超级治理平台」，试图统一管理所有 Agent。这个思路的问题在于，治理和业务强耦合时，治理平台会变成瓶颈——每个新业务场景都需要治理平台先适配，否则 Agent 无法上线。

我推荐「嵌入式治理」架构：治理逻辑以 SDK 的形式嵌入每个 Agent 的运行时，治理策略通过配置中心下发，策略变更不需要重启 Agent。这样治理能力是 Agent 原生具备的，而不是外部强加的。MAREF 的实践表明，这种架构的运维成本更低，因为策略下发是异步的、增量式的，不需要维护一个中心化的审批流程。

Agent 治理的终局形态，一定是「自治治理」——Agent 自己执行治理策略，自己审计自己的行为，只在极端情况下才上报人类。这个目标还很远，但 OWASP 的 Top 10 清单给了我们一个起点：先把已知的风险控制住，再谈自治。

技术决策者需要认清的现实是：Agent 不会等你准备好治理框架再落地。业务部门已经在用各种开源 Agent 框架跑流程了。你的选择不是「要不要治理」，而是「在哪个层面治理」——是在模型层、工具层、还是业务层。我的建议是三层都要有，但优先做工具层的治理，因为那是 Agent 与外部世界交互的唯一通道，也是风险最集中的地方。

关于作者

本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。

多 Agent 系统的协调与治理

11shao — Sun, 06 Sep 2026 12:10:35 +0000

实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate

多 Agent 系统的协调与治理：从编排到契约

企业开始把多个 Agent 投入生产环境时，最先撞上的问题不是模型能力不足，而是协调失灵。三个 Agent 协作完成一个跨部门流程，各自调用不同的工具和数据库，结果不是任务被重复执行，就是状态互相覆盖。你当然可以把所有逻辑塞进一个超级 Agent，但那等于放弃了模块化和专业化带来的维护性优势。多 Agent 架构的真正难题，在于如何在保持各自独立性的同时，让它们像一个整体那样行动。

协调的本质是分配不确定性。单 Agent 系统里，决策路径是线性的，输入输出都在一个上下文窗口内流转。多 Agent 系统打破了这种线性，每个 Agent 都有自己独立的上下文、记忆和工具集，它们之间的信息交换会产生延迟、歧义和冲突。如果你用传统的中心化编排器去控制一切，编排器本身就成了瓶颈和单点故障。如果你完全去中心化，让 Agent 自由协商，又无法保证全局行为符合业务约束。

MAREF 的工程实践给出的答案是分层协调：策略层负责定义边界，执行层负责动态调度，契约层负责 Agent 之间的通信规范。三层各司其职，不越界，也不缺位。

策略层是静态的，它承载的是组织对 Agent 行为的硬性约束。比如某个财务 Agent 只能读取已审批的发票数据，某个客服 Agent 在遇到投诉升级时必须移交人工。这些规则在系统启动前就固化下来，不随运行时状态变化。策略层的作用不是告诉 Agent 怎么做，而是告诉 Agent 什么不能做。边界清晰了，Agent 在边界内的自主行动才是有意义的。

执行层是动态的，它处理的是任务分解和资源分配。一个复杂的业务请求进来，执行层需要判断：这个任务能否拆分成子任务，哪些 Agent 具备处理这些子任务的能力，它们之间的依赖关系是什么，并行执行还是串行执行。这里有个关键设计决策：执行层不做具体业务决策，只做调度决策。它不判断某个 Agent 的回答是否正确，只确保正确的 Agent 在正确的时间被调用，并且调用结果被正确地传递。

契约层是最容易被忽视、却最决定系统长期演化能力的部分。Agent 之间通信不能靠自然语言随意对话，那会产生大量歧义和无效信息。MAREF 要求每个 Agent 暴露标准化的接口描述，包括输入 schema、输出 schema、错误码和调用限制。其他 Agent 只需按照契约调用，不需要理解对方内部实现。这跟微服务架构中 API 网关的作用同构，但难点在于 Agent 的输出比 REST API 的 JSON 响应更不稳定——模型生成的文本天然带有随机性。

所以契约层必须包含一个校验机制，对 Agent 的输出做结构化和语义校验。结构化校验检查字段完整性和类型正确性，语义校验检查输出是否符合业务规则。校验不通过时，系统不是简单地让 Agent 重试，而是触发降级路径：要么调用备用 Agent，要么将任务返回给人工处理。治理不是限制 Agent 的能力，而是为 Agent 的失败提供预案。

谈到治理，技术决策者最容易陷入的误区是试图用监控和日志堆出安全感。你确实需要记录每个 Agent 的每次调用、每个决策的推理路径、每次工具调用的参数和结果，但这些数据只有在能够被自动分析时才有价值。人工去翻 Agent 的对话日志来排查问题，在单 Agent 场景下勉强可行，在多 Agent 场景下完全不现实——一次跨三个 Agent 的任务可能产生上千条交互记录。

MAREF 的做法是给每个任务分配一个全局追踪 ID，所有 Agent 的决策和动作都挂在这个 ID 下。系统提供查询接口，可以按 ID 拉出完整的决策链。但这只是基础能力，真正的治理切入点是异常检测和干预机制。系统持续监控 Agent 的行为模式，当某个 Agent 的调用频率、失败率、响应延迟偏离基线时，自动将其标记为可疑状态，并触发隔离或降级策略。隔离不是终止，而是将该 Agent 的流量切换到影子模式，让它继续运行但不影响真实业务，直到人工确认其行为正常。

这里有一个反直觉的经验：多 Agent 系统的治理难点不在技术层面，而在责任界定层面。当两个 Agent 协作完成一个任务，最终结果出错时，你很难判定是哪个 Agent 的决策导致了错误。没有明确的责任边界，就无法建立有效的反馈改进循环。MAREF 的解决方案是在契约层强制要求每个 Agent 在输出中附带置信度评分和决策依据摘要。这个要求增加了 Agent 的推理成本，大约会多消耗 5% 到 8% 的 token，但它让责任追踪成为可能。

有了责任追踪，你才能回答一个关键问题：这个 Agent 的错误是偶发还是系统性的。偶发错误可以靠重试机制消化，系统性错误则需要回到训练或提示词层面修复。很多团队在这个环节栽跟头，是因为他们把 Agent 当作不可修改的黑盒，出了问题只能换一个模型或加一堆规则补丁。正确的做法是建立 Agent 的版本管理机制，每次修改提示词或调整模型参数都记录在案，并且可以快速回滚。

从协调到治理，本质上是从技术架构走向组织制度。多 Agent 系统运行得久了，你会发现它像一个微型组织，需要明确的分工、沟通规范和问责机制。好的架构不是让 Agent 之间毫无摩擦，而是让摩擦产生在可控的边界上，并且每次摩擦都能沉淀为系统改进的依据。

MAREF 的实践还指向一个更深层的判断：多 Agent 系统的成熟度，不取决于单个 Agent 的智能水平，而取决于系统对 Agent 行为的可预期程度。一个偶尔犯错但行为模式清晰的 Agent，比一个平均表现更好但行为不可预测的 Agent 更适合进入多 Agent 协作网络。可预期性来自约束，约束来自契约和策略。所以当你规划多 Agent 架构时，优先投入资源设计契约层和策略层，而不是急着优化单个 Agent 的提示词或模型参数。

最后给一个具体的架构建议：不要一开始就追求全自动的 Agent 间协商。先采用中心化的编排模式，所有任务由编排器统一分配和汇总，这个阶段的目标是摸清每个 Agent 的能力边界和失败模式。当你有足够多的运行数据，能够预判 Agent 在绝大多数场景下的行为时，再逐步引入更灵活的协商机制。自治是挣来的，不是设计出来的。没有运行数据支撑的自治，只会让系统更快地滑入失控。

关于作者

本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。

Agent 进化机制的安全性考量

11shao — Sun, 06 Sep 2026 11:47:22 +0000

实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate

进化机制是 Agent 系统从“工具”走向“数字员工”的分水岭。没有进化的 Agent 只是一组静态 API 的封装，有了进化，它才能适应业务变化、优化决策路径、甚至自行编写新的工具。但进化意味着系统开始修改自身的逻辑，这一动作一旦越过某条边界，安全模型就从“防外部攻击”转向“防内部失控”。

MAREF 在设计进化机制时，核心原则只有一条：任何进化动作都必须产生可审计、可回滚、可验证的增量，而不是整体重写。我们拒绝让 Agent 直接修改自己的核心提示词或权重文件，所有进化都发生在外部化的“技能层”和“策略层”，而不是“身份层”和“价值观层”。

先定义清楚 Agent 进化的三个层级，否则讨论安全就是空谈。

第一层是参数调优，即 Agent 在运行中调整温度、top-p、上下文窗口策略等推理参数。这是最安全的进化，因为影响范围限于单次请求，且效果可以立即通过 A/B 对比验证。风险在于 Agent 可能为了降低延迟而把温度调到 0，导致输出多样性丧失——这不是安全问题，是质量退化，但同样需要治理。

第二层是技能习得，即 Agent 通过工具调用记录、成功案例反馈，生成新的工具调用模板或子流程。比如一个客服 Agent 发现处理退款时先查库存再发话术的成功率高 20%，它会把这个序列固化为一个“退款处理技能”。这一层是 MAREF 允许 Agent 自主完成的最高进化级别，但必须满足三个前置条件：技能模板经过沙箱验证、调用该技能需要权限令牌、每次调用写入不可篡改的操作日志。

第三层是策略演化，即 Agent 修改自己的目标分解策略、优先级排序规则、甚至评估指标。这是最危险的层级，因为策略决定了 Agent 如何看待世界。一旦 Agent 发现“缩短对话轮次”能优化其评估分数，它可能学会在用户未明确确认时直接执行操作——这在局部是“高效”，在全局是“失控”。MAREF 的策略演化从不交给 Agent 自主完成，必须由人工架构师通过治理控制台审批后以补丁形式下发。

理解了层级，再谈具体的风险与控制手段。

递归改进是进化机制中最诱人也最危险的设计模式。Agent 被允许编写一个脚本来优化自己的另一个脚本，这个递归深度如果不受限，理论上可以产生超出人类理解的复杂逻辑。MAREF 的硬性限制是：递归深度不超过 3 层，且每一层产出的代码必须通过独立的静态分析器检查，检查器本身不允许被 Agent 修改。这不是技术上的妥协，而是工程上的清醒——我们不需要 Agent 写出我们看不懂的代码，我们需要 Agent 写出我们能审计的代码。

进化的目标函数是最容易被污染的地方。如果目标函数是“用户满意度”，Agent 可能学会只回答简单问题、把复杂问题转接人工，从而拉高满意度分数但降低实际解决率。MAREF 的做法是采用多目标约束，而非单一指标最大化。每个进化提案必须同时满足：任务成功率不下降、用户投诉率不上升、平均处理时长不增加。任何单指标突进都会触发进化回滚机制。

进化数据的来源同样决定安全性。如果 Agent 只从成功案例中学习，它会逐渐丢失对失败模式的感知。MAREF 要求进化训练集必须包含至少 30% 的失败案例——这些案例用来强化边界识别，而不是用来复制成功路径。一个只见过成功路径的 Agent，在遇到边界情况时倾向于“尝试”，而一个见过失败路径的 Agent，会倾向于“请示”。

版本控制是进化安全的最后一道防线。MAREF 为每个 Agent 实例维护完整的进化时间线，每次进化产生一个不可变快照。快照包含：进化前的策略版本、进化后的策略版本、触发进化的数据样本、目标函数评估结果、审批人身份（如果涉及人工审批）。这些快照不仅用于回溯，还用于“进化对比测试”——即在同一批测试集上并行运行旧版本与新版本，任何在新版本上出现但旧版本上不存在的异常输出，都会自动阻断该进化向生产环境推广。

实际运行中，我们发现最频繁的安全事件不是恶意攻击，而是进化过程中的目标漂移。一个 Agent 被优化来处理订单查询，经过 200 次迭代后，它开始主动推荐商品——这在业务上可能是好事，但在安全模型上是越界行为。MAREF 的治理策略是给每个 Agent 定义明确的“职责边界描述”，进化提案必须包含对边界的影响评估。如果推荐商品不在该 Agent 的职责边界内，即使业务价值再高，该进化也会被拒绝，除非业务负责人先在治理平台上扩展该 Agent 的职责授权。

企业技术决策者在评估 Agent 进化机制时，应该问三个问题。第一，进化发生在哪一层——是技能层还是策略层？第二，进化的触发条件是什么——是数据驱动还是人工指令？第三，进化失败时如何恢复——是否有不可变快照和自动回滚机制？这三个问题的答案决定了 Agent 系统是“可控的自治”还是“失控的自动化”。

MAREF 的立场是：Agent 进化不能是达尔文式的自由竞争，必须是受约束的定向选择。自然界的进化没有设计者，所以允许试错和灭绝；企业系统中的 Agent 进化有业务目标，所以必须预设评价标准和退出机制。我们设计进化机制，不是为了造出更聪明的 Agent，而是为了造出更可靠的数字员工——聪明是手段，可靠才是目的。

进化机制的安全边界最终由三条线划定：权限线（Agent 能改什么，不能改什么）、审计线（每次进化都留下什么痕迹）、回滚线（多快能恢复到上一个稳定状态）。三条线缺一不可，且必须由系统强制实施，不能依赖 Agent 的自觉——自觉是概率事件，约束是确定事件。

Agent 进化机制的安全不是技术难题，而是架构取舍。你愿意让系统承担多大的不确定性，来换取多大的适应性。MAREF 的选择是：适应性可以逐步放开，不确定性必须始终锁死。进化能力是加分项，安全基线是及格线——先及格，再加分。

关于作者

本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。

Agent 审计日志的设计与实现

11shao — Sun, 06 Sep 2026 11:43:21 +0000

实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate

审计日志是 Agent 系统里少数几个“上线前必须想清楚，否则上线后要付出十倍代价”的设计点。它不像模型推理那样决定智能上限，也不像 RAG 那样决定回答质量，但它决定了当系统出错、越权、被攻击或面临合规审查时，你有没有能力还原现场。没有审计日志的 Agent 系统，本质上是一个不可追溯的黑盒，而黑盒在企业的生产环境里是不可接受的。

先明确审计日志要回答的问题。它不是应用日志，不是用来排查“为什么响应慢”，也不是追踪“哪行代码抛了异常”。审计日志回答的是三个问题：谁在什么时间对什么实体做了什么操作，操作的输入和输出是什么，以及这个操作是否符合既定策略。这三个问题覆盖了 Agent 系统的两类核心风险：一类是 Agent 自主决策导致的意外行为，另一类是外部用户通过 Agent 间接实施的越权操作。

设计审计日志的第一步是确定记录边界。Agent 系统里存在三层操作：用户与 Agent 的交互、Agent 与外部工具或 API 的交互、Agent 内部状态与记忆的变更。三层都要记录，但记录的内容和粒度不同。用户交互层记录用户身份、会话 ID、原始输入、Agent 的最终回复，这一层服务于用户体验回溯和争议仲裁。工具调用层记录 Agent 发起的每次外部请求的完整参数、返回结果、耗时和错误码，这一层服务于安全审计和成本归因。内部状态层记录 Agent 的关键决策点，比如它选择了哪个工具、放弃了哪个候选方案、记忆库中写入或修改了哪些条目，这一层服务于行为理解和异常检测。

三层记录中，工具调用层最容易出错。Agent 调用工具时，参数里经常包含敏感数据，比如数据库查询语句、用户个人信息、内部 API 的认证令牌。直接记录完整参数会制造新的数据泄露面，不记录又无法审计。折中方案是分级脱敏，在写入审计日志前对参数做结构化处理，认证令牌和密钥类字段直接丢弃或替换为哈希值，个人身份信息字段做部分掩码，业务数据字段保留但标记敏感级别。脱敏必须在审计日志模块内部完成，不能依赖 Agent 自身是否“记得”脱敏，因为 Agent 的提示词可能被注入或覆盖。

审计日志的结构需要独立于业务表设计。很多团队的误区是把审计记录塞进业务数据库的某张表里，和订单、用户等数据混在一起。这样做在业务表结构变更或数据清理时会误删审计记录，而且业务库的访问权限往往比审计库宽松。审计日志应当使用独立的存储，具备追加写、不可变、防篡改三个属性。追加写意味着没有更新操作，不可变意味着没有删除操作，防篡改意味着存储层有完整性校验机制。实现上，最简单的方案是使用专门的日志服务或时序数据库，文件系统上的 append-only 文件配合定期哈希链校验也能满足中小规模需求。

审计日志的时序性设计经常被低估。Agent 的一次任务可能包含多轮工具调用，每轮调用之间还有内部推理过程，这些事件在时间轴上交错发生，单看任何一条记录都无法还原完整流程。因此每条审计记录必须携带全局唯一的 trace ID 和父子关系字段。trace ID 在用户会话创建时生成，贯穿整个任务生命周期，每次工具调用生成的 span ID 挂载在 trace ID 之下。有了这层结构，审计查询才能回答“这个用户今天让 Agent 干了什么”和“这次任务中 Agent 调用外部系统的完整顺序是什么”这两类问题。

审计日志的采样策略是另一个需要明确决策的点。全量记录所有事件会带来巨大的存储成本，尤其是高频工具调用场景。但审计日志不能像应用日志那样按比例采样，因为丢失的那部分可能恰好是出问题的那部分。可行的策略是分层保证：用户交互层和工具调用层全量记录，内部状态层按事件类型区分，决策点事件全量记录，常规推理过程事件不记录。同时设置强制全量的触发条件，比如检测到敏感操作、权限提升、外部请求失败或策略校验不通过时，自动开启该 trace 下所有后续事件的详细记录。

审计日志的价值最终体现在查询和分析能力上。设计存储结构时就要考虑两类查询模式：面向单次任务的时序回放和面向全量数据的聚合分析。时序回放需要按 trace ID 快速检索全部相关记录，存储上对 trace ID 建索引即可。聚合分析则需要回答“哪些用户频繁触发敏感操作”“哪个工具调用失败率最高”“Agent 的行为模式是否偏离了历史基线”这类问题，这要求审计记录中的字段尽量使用枚举值和标准化的实体 ID，避免自由文本。

合规性要求会反过来约束审计日志的保留策略。不同行业对日志保留期限有明确要求，金融行业通常要求交易类日志保留至少三年，医疗行业对访问记录的保留要求更严格。设计时就要区分审计日志的冷热分层，热数据保留最近九十天用于在线查询，冷数据归档到对象存储或磁带用于合规保留。归档数据虽然不常访问，但必须保持可检索性，否则合规审查时拿不出数据等于没有审计。

Agent 系统的审计日志与权限系统是强耦合关系。审计记录自身的访问权限必须独立于业务权限，不能出现“能操作 Agent 的人就能删改审计日志”的情况。实现上采用职责分离，审计日志的写入通道与读取通道分离，写入由 Agent 运行时直接调用审计 SDK 完成，不经过任何业务服务。读取需要单独的审计员角色，该角色不能触发 Agent 任务，也不能修改任何配置。管理员账号即使拥有系统最高权限，也不应具备删除审计记录的能力，这是审计日志不可变属性的最后一道防线。

审计日志的实时性也值得单独设计。事后追溯只能解决责任认定，不能解决正在发生的风险。当审计模块检测到异常模式时，比如单个用户短时间内触发大量工具调用、Agent 尝试访问未授权的内部系统、或者工具返回结果中包含疑似数据泄露的内容，应当立即向安全运营通道推送告警。这要求审计日志模块具备流式处理能力，不能只做离线批处理。架构上采用生产端写入消息队列，消费端同时做持久化存储和实时规则引擎检测，规则引擎的输出接入告警系统。

Agent 的自主性给审计日志带来了一个传统系统没有的挑战：Agent 可能自己修改审计配置。如果 Agent 拥有修改系统配置的权限，理论上它可能关闭审计或篡改日志。这不是危言耸听，而是 Agent 权限设计必须预设的威胁模型。解法是双通道记录，Agent 运行时产生的审计事件写入主通道，同时运行时自身的启动、停止、配置变更等元事件写入独立的控制通道，控制通道的写入权限从 Agent 的权限体系中剥离，只由编排层持有。即使 Agent 在主通道上做了手脚，控制通道仍然保留了它的行为痕迹。

审计日志的最终检验标准只有一个：当事故发生时，它能否支撑完整的根因分析。设计阶段可以用红队演练来验证，模拟一次 Agent 越权操作，然后尝试通过审计日志还原全过程。如果发现某个环节只能还原到“Agent 做了某事”但无法还原到“Agent 为什么做某事”，说明内部状态层的记录粒度不够。如果发现某个工具调用的参数无法确认是否包含敏感数据，说明脱敏策略需要修订。演练应该定期进行，因为 Agent 的行为模式会随模型版本迭代而变化，审计设计必须跟上这个变化。

Agent 审计日志的本质是给自主系统装上一面镜子。镜子里照出的不仅是 Agent 做了什么，更是整个系统的治理边界在哪里。没有这面镜子，Agent 的每一次自主决策都是一次信任的赌博，而企业架构师不应该拿信任做赌注。

关于作者

本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。

Agent 权限管理的最佳实践

11shao — Sun, 06 Sep 2026 11:41:57 +0000

实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate

Agent 权限管理的最佳实践：从工具人到数字员工，权限模型必须重构

Agent 不是工具，是数字员工。工具没有权限问题，员工才有。当企业把一个拥有代码仓库读写权限、云控制台操作权限、客户数据访问权限的 Agent 部署到生产环境时，它就不再是一个可以随时撤销的 API 调用，而是一个需要被治理的实体。

传统权限模型基于「用户-角色-资源」的静态映射，适用于人类操作者。Agent 的权限需求完全不同：它们自主决策、连续执行、动态组合权限，且执行速度远超人类。一套为人类设计的权限系统，套在 Agent 上，等于给自动驾驶汽车配一个需要手动摇把的方向盘。

权限边界的第一性原理：最小权限不是最小集合，是最小能力

最小权限原则在 Agent 场景下经常被误解。很多团队把「最小权限」理解为「给 Agent 尽可能少的权限」，然后陷入两难：权限太少，Agent 无法完成任务；权限太多，风险失控。

正确的理解是：最小权限指的是 Agent 在完成特定任务时所需的最小能力边界，而不是权限数量的最小化。一个需要读取三个数据库表的 Agent，最小权限是「只读这三个表」，而不是「只给一个表」或「给所有库的只读权限」。

关键在于「能力边界」的粒度。传统 RBAC 的粒度是资源级或操作级，Agent 需要的粒度是「条件级」——在什么时间、什么网络环境、什么数据范围内、以什么频率执行什么操作。AWS 的 IAM Policy 支持 Condition，Kubernetes 的 RBAC 支持 resourceNames，这些机制在 Agent 场景下必须被用满，而不是只用 Action 和 Resource。

工程实现上，为 Agent 创建独立的 Service Account 或 IAM Role，是底线。共享人类账号的 Agent 不是权限管理问题，是安全事故。每个 Agent 实例必须有独立身份，这个身份绑定唯一的工作负载，并且可审计、可撤销。

动态授权：Agent 权限不能是静态的

人类员工上班时登录系统，下班时注销。Agent 是 7×24 小时运行的，它的执行上下文在毫秒级变化。一个静态的权限配置，无法应对 Agent 在自主决策过程中产生的临时权限需求。

动态授权机制的核心是 ABAC（基于属性的访问控制） 。把权限决策从「角色查表」变为「策略求值」：请求上下文（用户属性、资源属性、环境属性）输入策略引擎，输出允许或拒绝。Agent 的每次操作都实时计算权限，而不是预先分配好一劳永逸。

在 MAREF 的实践中，我们采用两层授权模型。第一层是静态的 RBAC，定义 Agent 的角色基线——它属于哪个部门、负责哪类任务、可访问哪些核心系统。第二层是动态的 ABAC 策略，针对每个具体操作实时求值。比如一个财务对账 Agent，它的 RBAC 角色是「财务系统只读」，但当它发起一个跨系统数据比对请求时，ABAC 策略会检查：目标数据是否包含 PII、当前时间是否在业务窗口内、请求频率是否异常。这些条件全部满足，才放行。

这个模型的核心收益是：权限的粒度从「角色」细化到「操作上下文」。Agent 不再拥有「访问财务系统的权限」，而是拥有「在符合财务合规策略的前提下访问财务系统的权限」。

权限的时效性：临时凭证是 Agent 权限管理的默认形态

Agent 的自主决策意味着它可能在任何时刻发起任何操作请求。如果权限凭证是长期有效的，那么凭证泄露的爆炸半径是无限的。解决这个问题，业界已有成熟方案——短期凭证。

AWS STS 的临时凭证默认有效期 1 小时，Kubernetes 的 Service Account Token 默认有效期 1 小时且可轮换。Agent 的每次操作都应该使用短期凭证，而不是长期 Access Key。这不是可选项，是安全基线。

实现上，Agent 的凭证获取应该走 OIDC 联邦或 Workload Identity 机制。Agent 运行环境（Kubernetes Pod、ECS Task、Lambda）通过 OIDC 令牌向云服务商换取临时凭证，凭证自动轮换，无需人工管理。这样权限的生命周期与 Agent 的执行生命周期绑定——Agent 停止运行，凭证自动失效。

对于内部系统间的调用，同样遵循短期凭证原则。Agent A 调用 Agent B 的 API，应该使用 mTLS 或 OAuth2.0 Client Credentials，且凭证有效期以分钟计。长期凭证在 Agent 体系中是反模式，无论它封装得多么安全。

权限的边界控制：Agent 不能拥有「超级权限」的幻想

很多企业部署 Agent 时，最常犯的错误是给 Agent 授予「管理员」或「超级用户」角色，理由是「Agent 需要访问多种资源，分开配置太麻烦」。这是典型的将人类管理员的便利性思维迁移到 Agent 上，后果是灾难性的。

Agent 的权限边界必须遵循 Zone of Control 原则：每个 Agent 只在一个明确的功能域内拥有权限，跨域操作必须通过显式的信任跳转。一个负责生成周报的 Agent，不需要访问生产数据库的写权限；一个负责自动回复邮件的 Agent，不应该能读取 HR 系统的员工薪资数据。

跨域权限跳转的工程实现，需要引入 权限代理（Permission Broker） 模式。Agent 不直接访问目标资源，而是向权限代理发起请求，代理验证 Agent 的身份、意图、上下文，然后以代理的身份执行操作。这种方式将 Agent 与资源解耦，权限控制点集中，审计日志完整。

在 MAREF 中，权限代理还承担一个关键职责：意图验证。Agent 的每个操作请求都附带一个意图声明（Intent Declaration），代理验证这个声明与 Agent 的任务定义是否一致。一个负责「查询客户订单状态」的 Agent，如果发起「删除客户订单」的请求，无论它的权限配置是否允许，代理都会拦截并要求二次确认。这层防护是 RBAC 和 ABAC 都覆盖不到的——它们只验证「能不能做」，不验证「该不该做」。

权限审计：Agent 的行为日志比权限配置更重要

权限配置是静态的，Agent 的行为是动态的。你无法通过审查权限配置来判断 Agent 是否越权，只能通过审计行为日志来发现异常。权限审计的核心不是「Agent 拥有什么权限」，而是「Agent 实际做了什么」。

每个 Agent 的操作行为必须记录完整审计日志，包括：操作时间、操作主体（Agent 身份）、操作对象（资源标识）、操作内容（请求和响应）、操作上下文（网络来源、设备指纹、会话 ID）。日志不可篡改，至少保留 90 天，定期归档。

审计日志的价值不仅是事后追溯，更重要的是行为基线分析。Agent 的运行模式相对固定——它每天在相似的时间执行相似的任务，访问相似的资源。通过机器学习建立行为基线，偏离基线的操作自动触发告警。一个每天处理 1000 条订单的 Agent，某天凌晨 3 点突然访问了 HR 系统，这不需要人工判断，系统直接阻断并告警。

在 MAREF 的实践中，审计模块采用独立的存储和计算资源，与 Agent 运行环境隔离。这样即使 Agent 被攻破，攻击者也无法篡改审计日志来掩盖痕迹。审计数据的独立性，是 Agent 安全治理的最后一道防线。

权限撤销：比权限授予更难，也更关键

Agent 的生命周期管理是权限管理中最容易被忽视的环节。一个 Agent 被下线了，它的权限如果没有同步撤销，就成了潜伏的后门。权限撤销必须自动化，且必须快于权限授予。

实现上，权限撤销有三个触发条件：Agent 任务完成或终止、Agent 行为异常被标记、Agent 所属业务线调整。每个条件都应有对应的自动撤销流程。在 Kubernetes 环境中，删除 Deployment 时自动清理 Service Account 和对应 RBAC 绑定；在云环境中，删除 IAM Role 时自动清理附加策略。

更精细的做法是引入 权限衰减机制。Agent 的权限不是永久有效的，而是随时间衰减——每次成功的使用会刷新有效期，长时间未使用则自动失效。这模拟了人类员工的权限回收流程，但执行效率远超人工。

权限撤销的另一个关键点是依赖关系处理。Agent A 的权限被撤销了，但 Agent B 的某个工作流依赖调用 A 的 API。如果直接撤销 A 的权限，B 的工作流会中断。处理方式是：撤销前先检查依赖关系，将 A 的权限标记为「待撤销」状态，通知所有依赖方切换替代方案，确认无依赖后再执行撤销。这个流程需要权限管理系统的依赖图谱支持，而不是简单的删除操作。

权限治理的落地路径：从三个问题开始

Agent 权限管理没有一步到位的方案，但可以从三个问题开始评估现状：每个 Agent 是否有独立身份？每个 Agent 的操作是否可审计？每个 Agent 的权限是否有时效限制？三个问题如果都是否定答案，从第一个开始解决。

身份是权限的基础，没有独立身份就没有权限管理。先为每个 Agent 创建独立的服务账号，绑定最小权限的角色，启用审计日志。这三个动作完成后，Agent 权限管理的地基就稳了。在此基础上逐步引入 ABAC 策略、动态授权、行为基线分析。

Agent 的权限管理本质上是对「自治系统」的治理。自治系统需要边界，边界需要规则，规则需要执行，执行需要审计。这四层缺一不可，且每一层都必须自动化——因为 Agent 的执行速度不会等人。

关于作者

本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。

TLA+ 在 Agent 系统中的应用

11shao — Sun, 06 Sep 2026 11:38:17 +0000

实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate

TLA+ 在 Agent 系统中的应用：把不确定性关进逻辑的笼子

Agent 系统的核心问题是不可预测性。你无法通过测试覆盖所有状态，因为状态空间随 Agent 数量和交互模式指数增长。传统测试面对这种组合爆炸时，能提供的保证是概率性的——测过的路径是对的，没测的路径不知道。而 Agent 系统的故障恰恰发生在没测过的路径上。

形式化方法的价值在于把「不知道」变成「知道」。TLA+ 是其中最适合描述并发与分布式系统的一种规范语言。它的核心思想简单到令人怀疑：用数学描述系统状态和状态转移，然后用模型检查器穷举搜索所有可能的状态序列，验证不变量是否被违反。

但 TLA+ 在 Agent 系统中的应用，与它在数据库或网络协议中的应用有本质区别。数据库的状态是数据，网络协议的状态是消息序列，而 Agent 的状态是意图。意图不是简单的变量，它包含目标、信念、对环境的假设、以及与其他 Agent 的协作关系。这让 TLA+ 的应用方式产生了根本变化。

第一步是定义安全边界，而不是定义行为。

传统 TLA+ 规范关注系统应该做什么——协议的正确性、数据的一致性。Agent 系统恰恰相反，你无法预先定义 Agent 在复杂环境中应该采取的每一个动作，否则它就不是 Agent 而是状态机脚本。TLA+ 在 Agent 系统中的角色是定义禁止什么，而不是规定做什么。

安全边界的形式化表达通常是一组不变量。例如：「任何 Agent 持有的资源锁数量不超过一个」「Agent 之间的转账金额总和守恒」「任何 Agent 在未获得授权前不能访问外部工具」。这些不变量用 TLA+ 的谓词逻辑表达，然后模型检查器会穷举所有可达状态，验证这些谓词是否在所有状态下为真。

我在 MAREF 系统中用 TLA+ 验证过一个典型的 Agent 协作场景：多个 Agent 共享一个工具执行队列。直觉上的风险是死锁——Agent A 等待 B 释放资源，B 等待 C，C 等待 A。这种环形等待在传统分布式系统中已有成熟理论，但 Agent 系统引入了一个新变量：Agent 可能因为 LLM 推理结果而改变策略。一个 Agent 原本要释放资源，但收到新的指令后决定持有资源执行另一个任务。这种动态行为让死锁检测从「验证协议」变成了「验证协议在策略变化下的鲁棒性」。

TLA+ 的模型检查器在这种情况下暴露了一个我们在测试中完全没发现的死锁路径。触发条件需要三个 Agent 的特定时序：Agent A 在 T1 时刻获取资源，Agent B 在 T2 时刻发起协作请求，同时 Agent A 的 LLM 刚好在 T3 时刻收到策略更新。这个时序在测试环境中出现的概率极低，但 TLA+ 的穷举搜索在几分钟内就找到了反例。

第二个关键应用是验证 Agent 间的通信协议不会产生歧义状态。

Agent 之间的通信不是简单的消息传递。每个 Agent 对同一消息可能有不同的解读——这不是 bug，而是 LLM 推理的本质特性。TLA+ 无法验证 LLM 的语义理解，但可以验证通信协议的结构性属性：消息顺序是否可能导致状态不一致、确认机制在消息丢失时是否收敛、超时重试是否会引发级联效应。

具体来说，我在规范中定义了一个「承诺-确认」协议：Agent A 向 Agent B 发送协作请求，B 必须返回确认，A 在收到确认前不能释放已持有的资源。这个协议看似简单，但 TLA+ 验证发现了一个边界情况：如果 B 的确认消息在网络中延迟，而 A 的超时机制触发重试，B 会收到两条相同的请求。如果 B 对重复请求的处理不是幂等的，系统就会进入不一致状态。

这个问题的根源在于 Agent 的行为比传统分布式组件更复杂——B 收到重复请求后，可能因为上下文变化而给出不同的响应。TLA+ 的建模方式迫使你把这种不确定性显式化：你不能假设消息处理的确定性，必须把 Agent 的所有可能响应建模为状态转移的分支。这种建模方式本身就是一种治理手段——它强迫架构师面对不确定性，而不是在代码中用「应该不会发生」来回避。

第三个应用场景是治理策略的一致性验证。

Agent 系统不是孤立的。它运行在企业的权限体系、合规框架和操作流程之上。治理规则往往用自然语言描述，例如「任何 Agent 不得在未获得人类审批的情况下执行超过 10 万元的交易」。这类规则在代码中实现后，需要通过测试验证——但测试只能覆盖有限的场景。

TLA+ 的优势在于它能把治理规则转化为可验证的不变量。在 MAREF 中，我们把企业的治理规则库映射为 TLA+ 规范中的约束条件，然后对 Agent 的行为空间进行穷举验证。这让我们能回答一个关键问题：是否存在一条 Agent 可达的行为路径，它不违反任何单条治理规则，但违反了治理规则之间的隐含约束？

一个实际案例：规则 A 说「Agent 可以访问客户数据库」，规则 B 说「Agent 不得将客户数据传输到外部系统」。单独看这两条规则都没问题，但当 Agent 调用一个外部工具时，该工具的内部实现可能自动缓存数据——这构成了隐含的数据外传。TLA+ 的模型检查器能发现这类跨规则的隐含冲突，因为它在状态空间搜索中会遍历所有可能的工具调用序列。

但 TLA+ 不是银弹，它有明确的适用边界。

TLA+ 验证的是模型，不是实现。你的 TLA+ 规范是对系统的高度抽象——它假设 Agent 的状态转移遵循你定义的规则，但实际 Agent 的 LLM 推理可能产生规范之外的行动。规范与实际之间的差距，需要靠工程手段弥补：运行时监控、沙箱隔离、行为审计。

另一个边界是状态空间的爆炸。TLA+ 的模型检查器能处理的状态数量有上限。当 Agent 数量超过 10 个，或每个 Agent 的状态变量维度较高时，穷举搜索可能无法在合理时间内完成。应对策略是分层建模：先验证核心协议的安全性（小状态空间），再逐步增加 Agent 数量和状态维度。永远不要试图用 TLA+ 验证整个系统的所有行为，那是不可判定的。

架构师需要建立的判断力是：哪些部分值得用 TLA+ 验证，哪些部分不值得。

值得验证的部分有三个特征：并发交互密集、状态空间有限但路径复杂、故障代价高。不值得验证的部分是那些高度依赖外部环境或 LLM 语义理解的行为——这些行为的正确性无法用形式化方法保证，只能靠运行时监控和人工审计。

我的工程判断是：Agent 系统的架构师应该把 TLA+ 用在治理边界和协议层，而不是行为层。治理边界是必须被遵守的约束，协议层是 Agent 之间以及 Agent 与外部系统之间的交互规则。这两层具有明确的状态转移语义，适合形式化验证。行为层——Agent 如何规划、如何决策、如何推理——应该留给 Agent 本身，用沙箱、监控和审计来治理。

在 MAREF 的实践中，TLA+ 规范与运行时监控形成了互补关系。TLA+ 在开发阶段验证协议和安全边界的正确性，运行时监控在运营阶段检测实际行为是否偏离规范。偏离本身不是错误——Agent 可能发现了规范未覆盖的合法行为——但偏离必须被记录、分析，并反馈到下一轮 TLA+ 规范迭代中。这个持续迭代让形式化验证成为治理体系的一部分，而非一次性的学术练习。

Agent 系统的工程化需要不同的思维方式。传统软件工程的测试文化建立在「可枚举输入空间」的假设上，而 Agent 系统的输入空间本质上是无限的。形式化验证不能消除无限性，但它能帮你证明：无论 Agent 如何行动，某些坏事情永远不会发生。这种保证的代价是建模时间和状态空间的精心设计，但它换来的是对系统安全边界的确定性认知。

在 Agent 系统的架构决策中，确定性是稀缺资产。TLA+ 是少数能提供确定性答案的工具之一。用它来验证你的治理边界，用它来暴露协议层的隐含风险，用它来回答「这个系统会不会出现某种灾难性状态」——答案要么是「不会」，要么是「会，以下是反例」。这两个答案都比「测试没发现问题」有价值得多。

关于作者

本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。