docs(concepts): 新增「智能体权限边界」——谁动手按谁的权限算

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)

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)

docs/04-concepts/index.md

@@ -28,6 +28,7 @@ DesireCore 围绕"培养并托管数字同伴"这一核心理念，构建了一
 | [算力模型](./compute-model) | 自带钥匙，自选引擎 | 想理解 AI 模型配置 |
 | [智能任务编排](./task-orchestration) | 自动拆解任务、匹配最佳智能体的"项目经理" | 想理解任务分配机制 |
 | [Auto Dream](./auto-dream) | 无损遗忘，在压缩中保留价值 | 想理解记忆整合机制 |
+| [智能体权限边界](./agent-permission-boundary) | 谁动手就按谁的权限算，越权责任在执行方 | 想理解多同伴协作时的权限归属 |
 
 ## 阅读建议
 

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)

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)

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