这页不是吓人，是帮你排掉最贵的错误
真正危险的反模式通常不是“完全不会”，而是“看起来已经差不多能用了”，于是它被一路带进真实工作流。
一类：配置越写越大，复杂度先失控
反模式 1：SOUL.md 太长
问题不只是“写得啰嗦”，而是：
- 每次调用都在重复付费
- 重要规则被废话稀释
- 风格、流程和边界混在一起，后面很难维护
更稳的做法：
- 把核心原则压短
- 把工作流和工具规则拆进单独文件
- 让系统提示只保留必须长期生效的东西
反模式 2：还没跑稳就做大全配置
如果你第一次就想同时写：
- 多模型路由
- 多条 fallback
- 一堆 skills
- 多个渠道
- 成本策略
那后面一旦出错，你会很难判断是哪一层坏了。
二类：权限开得比需求更快
反模式 3：一上来就给完整写权限
更稳的顺序通常是：
- 第一周只读
- 第二周有限写
- 第三周再考虑更完整的执行动作
反模式 4：开了 send_as_user 却没把回滚想清楚
这类权限危险不在于“能不能用”，而在于：
- 它能以你的身份做动作
- 动作一旦发出，很难撤销“已经造成的影响”
反模式 5：把外发、读取、修改都放进一个默认允许集合
消息发送、文档修改、任务写入、外部请求，这几类动作不该走一个粗暴的默认允许策略。
三类：运行习惯太随意
反模式 6：不区分 dev / staging / prod
生产环境最常见的不是“代码本身有毒”，而是测试和生产共用：
- 同一配置
- 同一密钥
- 同一预算
- 同一工作区
更稳的思路：
环境分层
dev: 便宜模型 + 更低预算 + 可频繁试错
staging: 预发布验证 + 接近真实流程
prod: 稳定模型 + 严格限制 + 清晰审计
反模式 7：没有定期复盘成本和效果
如果你从不看：
- 每周账单
- 错误率
- 任务完成率
- fallback 触发频率
那很多问题只会在系统已经扩大之后才被看见。
四类：Docker 和工作区路径想当然
反模式 8：容器里继续用 localhost
容器内访问宿主机服务时，路径和网络都不能按宿主机直觉理解。最常见的问题是：
- 你以为自己在连本机服务
- 实际容器里那个
localhost指向的是容器自身
反模式 9：AGENTS.md、SOUL.md 文件名和位置不对
这类问题最烦人的地方在于：
- 机器人表面还能回复
- 但你以为写好的规则根本没被吃到
五类：多 Agent 上得太早
反模式 10：每个 Agent 都传完整上下文
这会直接带来：
- 上下文膨胀
- 成本上升
- 角色分工反而不清楚
更稳的做法是：
- 传摘要
- 传共享记忆 ID
- 只在需要时读取完整材料
反模式 11：多个 Agent 共用同一状态目录
这类问题最容易导致：
- 认证冲突
- 会话污染
- 调不清谁在用哪组入口
六类：排障时直接重装
反模式 12：没收敛问题层，就开始重装
这是最常见、也最浪费时间的错误。
更值的顺序应该是：
先收敛，不先重装
1. 先判断坏在哪一层
2. 先跑 doctor
3. 再看日志和 gateway
4. 最后才考虑重装
你最该周期性复查的 8 件事
周期性复查 checklist
1. SOUL.md 是否又写长了
2. 是否挂了过多 skills 和工具
3. 是否有权限开得太早
4. 是否缺少成本上限
5. 是否 dev/prod 混用
6. 是否路径和工作区规则已经混乱
7. 是否多 Agent 共享了不该共享的状态
8. 是否已经很久没看账单、错误率和更新状态