From cbeb784df5a93e0cef3cbf59967401b29055a3d6 Mon Sep 17 00:00:00 2001 From: yi-ge Date: Wed, 29 Jul 2026 19:57:32 +0800 Subject: [PATCH] =?UTF-8?q?docs(concepts):=20=E6=96=B0=E5=A2=9E=E3=80=8C?= =?UTF-8?q?=E6=99=BA=E8=83=BD=E4=BD=93=E6=9D=83=E9=99=90=E8=BE=B9=E7=95=8C?= =?UTF-8?q?=E3=80=8D=E2=80=94=E2=80=94=E8=B0=81=E5=8A=A8=E6=89=8B=E6=8C=89?= =?UTF-8?q?=E8=B0=81=E7=9A=84=E6=9D=83=E9=99=90=E7=AE=97?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 同伴之间开始互相协作（委派、发消息、插话、打断）后，必须回答一个问题：甲让乙做事， 按谁的权限算？ 本文说明 DesireCore 的选择与理由：**按执行方自己的权限算，越权责任在执行方**。 并解释了为什么没有采用「按发起方权限收窄」的直觉方案——它会让专业分工失效 （权限小的助理无法请权限大的专家干本职工作）、让责任随「谁指使」而变、 且在多层协作下权限一路归零，反而逼用户给每个同伴开更大的权限。 同时说明这不削弱可控性：授权来源仍然唯一（只由用户配置），三层可控性完整生效， 且边界更容易检查——只需回答「我给这个同伴开了什么权限」。 中英双语；委派式交互模型页与两个语种的概念索引同步加了入口。 顺带把英文索引缺失的 Task Orchestration 一行补齐。 --- docs/04-concepts/02-delegation-model.md | 5 + .../12-agent-permission-boundary.md | 91 +++++++++++++++++++ docs/04-concepts/index.md | 1 + .../04-concepts/02-delegation-model.md | 5 + .../12-agent-permission-boundary.md | 91 +++++++++++++++++++ .../current/04-concepts/index.md | 1 + 6 files changed, 194 insertions(+) create mode 100644 docs/04-concepts/12-agent-permission-boundary.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/04-concepts/12-agent-permission-boundary.md diff --git a/docs/04-concepts/02-delegation-model.md b/docs/04-concepts/02-delegation-model.md index e3b5b7f..e351f7f 100644 --- a/docs/04-concepts/02-delegation-model.md +++ b/docs/04-concepts/02-delegation-model.md @@ -107,8 +107,13 @@ DesireCore 采用的是**委派模式（Delegation）**：你把事情"交代" 3. **能力可成长**：同伴的能力是累积的。今天教了合同审查，明天教了邮件写作，后天它就能处理更复杂的综合任务 4. **风险可控**：通过固化步骤、灵活步骤和人闸门的组合，你可以精确控制同伴的自主程度 +## 同伴之间也能互相委派 + +委派不只发生在"你 → 同伴"之间，同伴与同伴之间同样可以互相委派、发消息、插话甚至打断。此时权限按一条固定规则界定：**谁动手，就按谁的权限算**——被请求的同伴仍然完整地按它自己被授予的权限行事，不会因为请求来自另一个同伴而放宽或收紧。详见 [智能体权限边界](./agent-permission-boundary)。 + ## 下一步 +- 想了解同伴之间协作时的权限归属？请阅读 [智能体权限边界](./agent-permission-boundary) - 想了解同伴如何控制风险？请阅读 [固化/灵活/人闸门](./step-types) - 想了解同伴做完事后的"工作报告"？请阅读 [回执系统](./receipt-system) - 想了解同伴怎么越来越聪明？请阅读 [自我进化](./self-evolution) diff --git a/docs/04-concepts/12-agent-permission-boundary.md b/docs/04-concepts/12-agent-permission-boundary.md new file mode 100644 index 0000000..57b8aae --- /dev/null +++ b/docs/04-concepts/12-agent-permission-boundary.md @@ -0,0 +1,91 @@ +--- +title: 智能体权限边界 +description: 多个智能体协作时，权限如何界定 -- 每个智能体只按自己的权限上限行事，越权责任在执行方 +keywords: [权限, 边界, 委派, 协作, 安全, 责任, Permission, Boundary] +--- + +# 智能体权限边界 + +## 一句话规则 + +**每个智能体做事时，只受它自己的权限上限约束；如果发生越权，责任在执行操作的那个智能体，而不是发起请求的那一方。** + +## 为什么需要这条规则 + +当同伴之间开始互相协作 -- 一个同伴请另一个同伴帮忙、给正在忙的同伴补一句话、或者打断它 -- 就出现一个必须回答的问题： + +> 甲同伴让乙同伴去做一件事，这件事按谁的权限算？ + +有两种可能的答案，DesireCore 选择了第二种。 + +### 方案一：按发起方的权限算（未采用） + +发起请求的同伴权限有多大，被请求的同伴就只能做多大范围的事 -- 相当于"权限只能越传越小"。 + +听起来更安全，但它在真实场景里会立刻崩溃： + +- **专业分工失效**：你的"日程助理"权限很小，它只能读日历。当它需要请"文书同伴"起草一份会议纪要时，如果按它的权限算，文书同伴连写文件都做不了 -- 而写文件正是你当初赋予文书同伴的职责。 +- **责任变得模糊**：一个操作到底该不该做，取决于"是谁让它做的"，而不是"做这件事的是谁"。同一个操作，A 请它做就允许、B 请它做就拒绝 -- 你没办法通过看一个同伴的配置来判断它到底能做什么。 +- **权限只减不增，最终归零**：多层协作下（甲请乙、乙请丙），权限一路收窄，链条稍长就什么都做不了。你会被迫给每个同伴都开更大的权限来"抵消"这种收窄 -- 结果是整体权限反而变大了。 + +### 方案二：按执行方自己的权限算（DesireCore 采用） + +**谁动手，就按谁的权限算。** + +- 乙同伴收到甲同伴的请求后，仍然完整地按**它自己**被授予的权限行事：它能读什么、能写什么、能调用哪些工具，只看它自己的配置。 +- 甲同伴无法通过"请乙帮忙"这个动作，让乙做出超越乙自身权限的事 -- 因为乙的权限本来就是它的天花板。 +- 反过来，甲也无法通过"请乙帮忙"给自己扩权 -- 乙做的事记在乙的账上，产出回到甲手里，但**执行发生在乙的边界内**。 + +## 越权责任在执行方 + +这条规则的另一半同样重要：**如果一个同伴做出了不该做的事，责任记在它自己头上。** + +- 每个同伴的能力边界写在它自己的配置里（工具授权、文件读写范围、风险等级），这份配置是你亲手定的。 +- 它做的每一次操作都进入**它自己的**回执与审计记录 -- 你看一个同伴的回执，看到的就是它真实做过的全部事情，不需要再去追"这是谁指使的"。 +- 因此排查问题时的路径是确定的：**先看是哪个同伴动的手，再看它的权限配置为什么允许了这件事。** + +换句话说，权限配置是一份**关于这个同伴的承诺**，而不是一份"关于谁能指使它"的规则。你调整一个同伴的权限，就调整了它在任何情况下的行为上限 -- 无论请求来自你、来自另一个同伴、还是来自定时任务。 + +## 这条规则覆盖哪些情况 + +只要是"一个同伴让另一个同伴做事"，都适用： + +| 场景 | 说明 | +|------|------| +| **委派任务** | 甲把一件事交给乙去做 | +| **发消息** | 甲给乙发一条消息，乙据此起一轮工作 | +| **插话** | 乙正在忙，甲往它当前这轮里补一句话 | +| **打断** | 甲中止乙正在进行的工作 | +| **团队分发** | 甲把同一件事同时发给多个同伴 | + +以上每一种，执行的那一方都按它自己的权限行事。 + +## 这不会削弱可控性 + +这条规则**不是**在放宽限制，它只是把限制放在了正确的位置： + +- **你的授权仍然是唯一的来源。** 同伴的权限从来只由你配置，同伴之间不能互相授予权限，也不能通过协作绕开你的设置。 +- **[三层可控性](./three-layer-control) 完整生效。** 不管这一轮是你发起的还是别的同伴发起的，高风险操作照样触发人闸门、照样有回执、照样可回滚。 +- **边界更容易检查。** 你只需要回答"我给这个同伴开了什么权限"，而不需要在脑子里模拟"如果它被某个别的同伴调用，权限会变成什么样"。 + +如果你不希望某个同伴具备某种能力，正确的做法是**收紧它自己的权限配置** -- 而不是指望别的同伴在调用它时替你把关。 + +## 一个具体例子 + +假设你有两个同伴： + +- **日程助理**：只能读日历，不能写文件 +- **文书同伴**：可以在 `~/文档/` 下读写 + +当日程助理请文书同伴"把今天的会议整理成纪要"时： + +1. 文书同伴按**自己**的权限执行 -- 它可以在 `~/文档/` 下写入纪要文件； +2. 但它同样**不能**越过自己的边界 -- 比如它无法去改 `~/系统配置/` 下的东西，即使日程助理这么要求； +3. 纪要写入这件事记在**文书同伴**的回执里； +4. 如果你认为"文书同伴不该有写文件的权限"，你要改的是**文书同伴的配置**，而不是限制日程助理去请它帮忙。 + +## 下一步 + +- 想了解整体的安全保障？请阅读 [三层可控性](./three-layer-control) +- 想理解同伴之间如何协作？请阅读 [委派式交互模型](./delegation-model) +- 想了解任务如何被分配给合适的同伴？请阅读 [智能任务编排](./task-orchestration) diff --git a/docs/04-concepts/index.md b/docs/04-concepts/index.md index 28dd91c..a02ab69 100644 --- a/docs/04-concepts/index.md +++ b/docs/04-concepts/index.md @@ -28,6 +28,7 @@ DesireCore 围绕"培养并托管数字同伴"这一核心理念，构建了一 | [算力模型](./compute-model) | 自带钥匙，自选引擎 | 想理解 AI 模型配置 | | [智能任务编排](./task-orchestration) | 自动拆解任务、匹配最佳智能体的"项目经理" | 想理解任务分配机制 | | [Auto Dream](./auto-dream) | 无损遗忘，在压缩中保留价值 | 想理解记忆整合机制 | +| [智能体权限边界](./agent-permission-boundary) | 谁动手就按谁的权限算，越权责任在执行方 | 想理解多同伴协作时的权限归属 | ## 阅读建议 diff --git a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/02-delegation-model.md b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/02-delegation-model.md index 4cf27d3..8b74b33 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/02-delegation-model.md +++ b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/02-delegation-model.md @@ -107,8 +107,13 @@ Example conversations: 3. **Capability Growth**: The companion's capabilities are cumulative. Today you taught contract review, tomorrow email writing, the day after it can handle more complex integrated tasks 4. **Risk Controllability**: Through combinations of hardened steps, flexible steps, and human gates, you can precisely control the companion's autonomy +## Companions Delegate to Each Other Too + +Delegation is not limited to "you → companion." Companions can delegate to, message, interject into, and even interrupt one another. Permissions in those cases follow one fixed rule: **whoever acts is bound by their own ceiling** — the requested companion still acts entirely within the permissions you granted it, neither widened nor narrowed by the fact that the request came from another companion. See [Agent Permission Boundaries](./agent-permission-boundary). + ## Next Steps +- Want to understand permissions across collaborating companions? Read [Agent Permission Boundaries](./agent-permission-boundary) - Want to understand how companions control risk? Read [Hardened/Flexible/Human Gate](./step-types) - Want to understand the "work report" after companions finish tasks? Read [Receipt System](./receipt-system) - Want to understand how companions get smarter? Read [Self-Evolution](./self-evolution) diff --git a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/12-agent-permission-boundary.md b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/12-agent-permission-boundary.md new file mode 100644 index 0000000..6ce5c4e --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/12-agent-permission-boundary.md @@ -0,0 +1,91 @@ +--- +title: Agent Permission Boundaries +description: How permissions work when agents collaborate -- every agent acts within its own ceiling, and accountability for overreach lies with the agent that acted +keywords: [permission, boundary, delegation, collaboration, security, accountability] +--- + +# Agent Permission Boundaries + +## The rule in one sentence + +**Every agent acts within its own permission ceiling. If something is done that shouldn't have been, accountability lies with the agent that performed the action -- not with whoever asked for it.** + +## Why this rule is needed + +Once companions start collaborating -- one asking another for help, adding a remark to a companion that is mid-task, or interrupting it -- an unavoidable question appears: + +> Companion A asks companion B to do something. Whose permissions apply? + +There are two possible answers. DesireCore chose the second. + +### Option 1: the requester's permissions apply (not adopted) + +The requested companion would be capped by whatever the requester is allowed to do -- permissions could only ever shrink as they are passed along. + +It sounds safer, but it falls apart immediately in real use: + +- **Specialization stops working.** Your "calendar assistant" has narrow permissions -- it can only read your calendar. When it asks the "writing companion" to draft meeting notes, capping the writer at the assistant's level means the writer cannot write files at all -- which is precisely the job you gave it. +- **Accountability becomes ambiguous.** Whether an operation is allowed would depend on *who asked*, not *who is doing it*. The same operation would be permitted when A asks and refused when B asks -- so you could no longer tell what a companion can do by looking at its configuration. +- **Permissions only shrink, eventually to nothing.** Across multiple hops (A asks B, B asks C), the ceiling narrows at every step until nothing is possible. You would be forced to over-provision every companion to compensate -- making the overall permission surface *larger*, not smaller. + +### Option 2: the executor's own permissions apply (DesireCore's choice) + +**Whoever acts is bound by their own ceiling.** + +- When companion B receives a request from companion A, it still acts entirely within the permissions **you** granted **B**: what it can read, what it can write, which tools it may call -- determined solely by B's own configuration. +- A cannot make B exceed B's own ceiling by asking, because that ceiling is absolute. +- Conversely, A cannot expand its own reach by asking B. Whatever B does is recorded against B, and the results come back to A -- but **the execution happened inside B's boundary**. + +## Accountability for overreach lies with the executor + +The other half of the rule matters just as much: **if a companion does something it shouldn't have, that is recorded against it.** + +- Each companion's capability boundary lives in its own configuration (tool grants, file read/write scope, risk level) -- a configuration you set yourself. +- Every operation it performs enters **its own** receipts and audit trail. Reading one companion's receipts tells you everything it actually did; you never have to trace back "who told it to." +- Investigation therefore has a fixed path: **first identify which companion acted, then look at why its permission configuration allowed it.** + +Put differently: a permission configuration is a **promise about that companion**, not a rule about who may command it. Adjusting a companion's permissions adjusts its behavioral ceiling in *every* situation -- whether the request came from you, from another companion, or from a scheduled job. + +## Which situations this covers + +The rule applies whenever one companion causes another to act: + +| Situation | Description | +|-----------|-------------| +| **Delegating a task** | A hands work to B | +| **Sending a message** | A messages B, and B starts a turn to handle it | +| **Interjecting** | B is busy; A adds a remark into B's current turn | +| **Interrupting** | A aborts what B is currently doing | +| **Fan-out** | A sends the same work to several companions at once | + +In every one of these, the acting party is bound by its own permissions. + +## This does not weaken controllability + +The rule is **not** a relaxation of limits -- it puts the limit in the right place: + +- **Your grants remain the only source.** Companion permissions are configured only by you. Companions cannot grant permissions to each other, nor collaborate their way around your settings. +- **[Three-layer controllability](./three-layer-control) applies in full.** Regardless of whether a turn was started by you or by another companion, high-risk operations still hit the human gate, still produce receipts, and are still reversible. +- **Boundaries are easier to verify.** You only need to answer "what did I grant this companion," rather than simulating "what would its permissions become if some other companion invoked it." + +If you don't want a companion to have a certain capability, the correct move is to **tighten that companion's own configuration** -- not to rely on other companions to gate it for you. + +## A concrete example + +Suppose you have two companions: + +- **Calendar assistant**: can read your calendar; cannot write files +- **Writing companion**: can read and write under `~/Documents/` + +When the calendar assistant asks the writing companion to "turn today's meeting into notes": + +1. The writing companion acts under **its own** permissions -- it may write the notes file under `~/Documents/`; +2. It equally **cannot** exceed its own boundary -- it cannot touch `~/SystemConfig/`, even if the calendar assistant asks it to; +3. Writing the notes is recorded in the **writing companion's** receipts; +4. If you decide the writing companion shouldn't be able to write files at all, what you change is **the writing companion's configuration** -- not the calendar assistant's ability to ask. + +## Next steps + +- Want the full picture on safety? Read [Three-Layer Controllability](./three-layer-control) +- Want to understand how companions collaborate? Read [Delegation Model](./delegation-model) +- Want to know how work is routed to the right companion? Read [Task Orchestration](./task-orchestration) diff --git a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md index 98baee3..c200cda 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md +++ b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md @@ -58,6 +58,7 @@ DesireCore is built around the core philosophy of "cultivating and hosting digit | [Compute Model](./compute-model) | Bring your own keys, choose your own engines | Want to understand AI model configuration | | [Task Orchestration](./task-orchestration) | Automatic task decomposition and best-agent matching — your "project manager" | Want to understand task distribution | | [Auto Dream](./auto-dream) | Lossless forgetting — preserving value through compression | Want to understand memory consolidation | +| [Agent Permission Boundaries](./agent-permission-boundary) | Whoever acts is bound by their own ceiling; accountability for overreach lies with the executor | Want to understand permissions across collaborating agents | ## Reading Recommendations