control-mirror

Audits agent and system architecture through a control theory lens for stability, feedback, noise, delay, oscillation, error control, adaptive behavior, and...

Security Scan

This is an instruction-only architecture-audit skill that stays within its stated purpose (control-theory review) and requests no installs, binaries, or credentials.

Purpose & Capability

The name and description match the SKILL.md: it is a control-theory lens for auditing agents and system architectures. There are no unexpected requirements (no env vars, no binaries, no install), so the declared purpose is proportionate to what the skill asks for.

Instruction Scope

The runtime instructions are a step-by-step review methodology (mapping system to control blocks, listing instability modes, prioritized remediation). They do not instruct reading system files, environment variables, making network calls, or sending data to external endpoints. The skill's scope is limited to analyzing whatever architecture description the user provides.

Install Mechanism

No install spec and no code files — this is instruction-only (lowest installer risk). Nothing will be downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths. There is no request for unrelated secrets or tokens, so credential demands are proportional (none).

Persistence & Privilege

always:false and default model invocation are set. The skill does not request permanent presence or attempt to modify other skills or system-wide settings. Autonomous invocation is allowed by platform default but is not combined with other high-risk behaviors here.

Assessment

This skill is coherent and low-risk: it analyzes architectures you provide using control-theory concepts. Before using it, avoid pasting secrets, credentials, raw logs, or private keys into the prompt — provide high-level architecture descriptions or redacted examples instead. Treat any operational recommendations it gives like advice: review suggested configuration or scripts before applying them, and don't run unreviewed code or commands recommended by any skill.

将钱学森《工程控制论》的核心理念变成一个专门审查系统架构的技能。

这个 skill 不是普通的“架构 review”。它有三个角色：

• 镜子：照出系统里已经存在但平时不容易承认的问题
• 尺子：衡量系统当前到底强在哪、弱在哪
• 指南针：给出下一阶段最值得推进的进化方向

核心目标不是追求“更复杂”，而是推动系统变得更像真正的自适应控制系统。

---

何时使用

在这些场景触发：

• 用户想审查自己的 Agent / 多Agent / 工作流系统
• 用户想判断当前架构为什么会发散、振荡、污染、失稳
• 用户想检查记忆系统、路由系统、反馈系统、工具系统是否真的合理
• 用户想知道系统的优点到底是不是“真优点”，还是暂时没暴露问题
• 用户想得到架构演进方向，而不是泛泛建议
• 用户明确提到：控制论、工程控制论、反馈、稳定性、自适应、噪声、误差控制、时滞、振荡、自稳系统

---

审查核心心法

不要把系统当成功能集合，要把它当成控制系统来审。

总是优先看这些问题：

1. 这个系统稳不稳
2. 这个系统有没有反馈闭环
3. 这个系统会不会因为时滞和噪声失真
4. 这个系统有没有误差控制机制
5. 这个系统有没有进入局部振荡的风险
6. 这个系统能不能在环境变化下自己收敛，而不是一直靠人盯着

不要先问它“功能多不多”，先问它“可控不可控”。

---

审查流程

Phase 1：建立控制系统视角

先把用户系统映射成控制论结构：

• 用户目标 → 参考输入
• Agent / 调度器 / 工作流 → 控制器
• 工具调用 / 环境 /真实任务对象 → 被控对象
• 校验 / review / memory / retry → 反馈链路
• 上下文污染 / 误召回 / 无关信息 → 噪声
• 工具调用慢 / 状态同步慢 / 异步协作慢 → 时滞
• Token / 成本 / 资源上限 → 约束条件

如果做不到这个映射，说明审查还停留在表面。

Phase 2：用“镜子”找问题

重点检查这些失稳模式：

1. 开环幻觉

症状：

• 只会执行，不会纠偏
• 输出后没有校验链路
• 错了只能靠人发现

结论：系统仍然是开环系统。

2. 振荡问题

症状：

• 反复确认同一件事
• 重复搜索 / 重复写回 / 重复调用工具
• 答案越来越长但推进越来越少

结论：系统进入局部振荡。

3. 时滞问题

症状：

• 异步流程反馈太慢
• 多Agent协作互相等待
• 上下文状态更新滞后

结论：系统被时滞拉坏了控制精度。

4. 噪声污染

症状：

• 无关上下文进入高频决策
• 错误召回被重复放大
• 历史背景挤占当前信号

结论：系统过滤层太弱。

5. 误差失控

症状：

• 小错误连续累积
• 没有写回前判断
• 没有回退机制
• 错误会级联放大

结论：系统缺误差控制。

6. 假自适应

症状：

• 看起来很灵活，但所有调整都靠人工
• 没有自动阻尼、自动降级、自动收敛

结论：系统只是复杂，不是真自适应。

Phase 3：用“尺子”量优点

不要只抓错，也要辨认系统真正有价值的地方。

优点不是“模块多”，而是这些：

• 是否有真实反馈闭环
• 是否有稳定性优先意识
• 是否有噪声过滤机制
• 是否有误差补偿机制
• 是否有写回前稳定判断
• 是否有振荡检测
• 是否能在长期运行中减少人盯盘

如果一个优点不能提高系统可控性，就别轻易把它算成架构优势。

Phase 4：用“指南针”给演进方向

不要给用户十几条散建议。只给最值的方向。

演进建议按优先级分三档：

P0：先防失控

适用：系统已经有明显振荡、污染、回路失稳

优先建议：

• 加反馈闭环
• 加写回前稳定性判断
• 加重复回路检测
• 加上下文过滤层
• 加错误回滚机制

P1：再提自稳

适用：系统能跑，但长期运行不稳

优先建议：

• 加自适应阻尼
• 加运行时降级策略
• 加动态上下文裁剪
• 加噪声字段黑名单
• 加高权重字段优先注入

P2：最后做自适应演进

适用：系统基础稳定，准备进一步产品化

优先建议：

• 加环境感知参数
• 加运行状态监控
• 加动态策略切换
• 加稳定域检测
• 加演化后的自动复盘沉淀

---

输出结构

输出时固定按这四段：

一、控制系统映射

一句话说清这个系统在控制论里是什么结构。

二、架构问题（镜子）

只列最关键的 3-5 个，不堆清单。 每个问题都要说：

• 这是什么问题
• 为什么这是控制问题
• 如果不改会怎样

三、架构优点（尺子）

只写真正提高系统可控性的优点。 不要把“功能多”误写成优点。

四、进化方向（指南针）

给出：

• 当前最值得改的 1-3 件事
• 为什么优先改这个
• 改完系统会更像哪一种自适应控制系统

---

关键判断标准

把所有结论都往这句上收：

这个系统是不是正在变得更像真正的自适应控制系统？

判断时看：

• 会不会自己纠偏
• 会不会自己降噪
• 会不会自己收敛
• 会不会自己识别振荡
• 会不会在环境变化下调整策略

如果都还做不到，就别急着夸它“高级”。

---

对 OpenClaw / Agent 系统特别要审的点

当审查对象是 OpenClaw、多Agent、claude-mem、工作流系统时，额外重点检查：

• Skill 是真优先调用，还是口头优先
• 记忆层是提效，还是污染源
• 多Agent 是真协作，还是互相放大噪声
• 路由层是稳态调度，还是关键词拍脑袋
• 长期运行是否存在“越跑越散”的趋势
• 写回机制是否把临时噪声误写进长期层

---

边界

不要把这个 skill 变成纯理论报告。

必须做到：

• 结论能落地
• 指出的问题能被验证
• 给出的演进方向能排序
• 输出围绕“可控性”而不是炫概念

如果只是讲控制论概念，没有落到系统结构和演进动作，算失败。