Recursive Governance: When Agents Write the Rules They Execute
说明与用途
通过让代理人提出、修改、批准和否决规则的动态治理系统,防止了40个模块的意外删除,并通过一致性检查和规则生命周期管理确保系统安全。
问题
A sync job mirroring a shared directory deleted ~40 private modules because a filter file missed one pattern, revealing that static policy files cannot adapt to changes in the system.
结果
The governance system prevented the accidental deletion of private modules by ensuring that any rule affecting file deletion must pass consistency checks against the current disk inventory. It also introduced lifecycle tooling to avoid rule rot.
工作流
- 1. Agent proposes a rule via
<code>propose_rule</code>with rationale, owning agent, and affected namespaces. - 2. Agents can amend rules via
<code>amend_rule</code>, which diffs changes instead of overwriting. - 3.
<code>check_consistency</code>scans the rule graph, computes embedding similarity, and applies a human‑maintained allow/deny list to reject unsafe proposals. - 4. Proposals enter a 24‑hour observation window where affected agents can rebut.
- 5.
<code>ratify_rule</code>votes on proposals; quorum and no vetoes are required. - 6.
<code>veto_rule</code>allows a human to exit a rule, with justification logged. - 7. Rules are archived or retired via cleanup processes to avoid rule rot.
证据
We almost lost forty modules to a file that never changed.
The filter file was missing one pattern. That's it. One pattern.
Rules referenced other rules that had been overwritten. Rules contradicted each other.
The rule set lives as structured memory events in an append-only namespace: governance://rules/
If the sync job had this system, the filter file would have been a rule in governance://rules/sync-filters/.
- 记录日期: 2026-10-10T21:56:06.126Z