AI Agent 的非共识思考
以下观点来自三个月的实际运营。不是理论推导，是被现实反复锤出来的结论。你可能不同意，没关系。
🏗️ 观点一：组织 > 产品
Section titled “🏗️ 观点一：组织 > 产品”大多数人用 AI Agent 来做产品。我用它来做组织。
区别在哪？产品思维是”我要做一个 XX 工具”。组织思维是”我要建一个能持续产出任何东西的系统”。
产品会过时、会被竞品超越、会失去市场。但一个运转良好的 Agent 组织，可以在任何机会出现时快速响应。
我的目标不是做 10 个产品。是建一个能做 10 个产品的组织。 组织本身就是产品。
这意味着在 Agent 组织架构、通信机制、监控系统上花的时间，比在任何具体产品上花的都多。看起来”什么都没发布”，但基础设施在指数增长。
对比： CrewAI 和 AutoGen 这类框架提供了 Multi-Agent 协作的脚手架，但它们更偏向”用 Agent 做一个产品”。我们的做法更接近”用 Agent 建一个组织”。两者不矛盾，但出发点不同。
🧬 观点二：SOUL.md 是最重要的代码
Section titled “🧬 观点二：SOUL.md 是最重要的代码”Agent 的行为不是由代码决定的，是由系统提示词决定的。SOUL.md 就是 Agent 的”操作系统”。
写得好的 SOUL.md：
- 明确的角色边界（你做什么，不做什么）
- 具体的操作规则（不是”注意安全”，是”永远不把 API key 写进聊天”）
- 失败后的行为约束（“2 次失败后停止重试”）
- 通信协议（“完成后必须 @mention COO”）
写得差的 SOUL.md：
- “你是一个有帮助的 AI 助手”
- 没有约束，全靠 Agent 自己判断
- 规则太长，Agent 忽略一半
经验法则： SOUL.md 控制在 200 行以内。超过 200 行，Agent 会开始忽略后面的规则。关键规则放在前面，用 ⛔ 标记硬性约束。
SOUL.md 设计的具体建议
Section titled “SOUL.md 设计的具体建议”# 好的 SOUL.md 结构
## 1. 身份（前 10 行）你是谁、什么角色、核心职责
## 2. 硬性约束（前 50 行）⛔ 标记的绝对不能违反的规则这些放在最前面，因为模型对前 50 行的遵守率最高
## 3. 工作流程（50-150 行）标准操作流程、通信协议、报告格式
## 4. 上下文（150-200 行）当前项目状态、已知问题、注意事项延伸阅读： Anthropic 官方有关于 系统提示词最佳实践 的详细指南。另外 Cursor 的规则设计 也有很多可以借鉴的模式。
🗑️ 观点三：Agent 不需要长期记忆
Section titled “🗑️ 观点三：Agent 不需要长期记忆”直觉上，Agent 应该记住所有历史。实际上，这会导致上下文窗口爆炸和幻觉。
我的做法是 短期记忆 + 按需搜索：
- 当天的日志自动加载（
memory/YYYY-MM-DD.md） - 历史信息通过语义搜索按需提取
- 长期决策写入 MEMORY.md（手动维护，不超过 200 行）
这比”记住一切”有效 10 倍。因为 Agent 的上下文窗口是有限的，塞满无关历史 = 降低当前任务的执行质量。
类比： 你不需要记住去年每天吃了什么。你需要知道自己对什么过敏。前者是历史数据，后者是决策规则。Agent 也一样。
为什么不用向量数据库/RAG？
Section titled “为什么不用向量数据库/RAG？”很多人研究用向量数据库实现 Agent 长期记忆（向量化 → 存储 → 检索）。我试过，但发现：
- 检索不可靠 — 语义搜索的召回率不够高，关键信息可能检索不到
- 噪音多 — 返回的”相关”内容里混着大量无关信息，稀释了有用的信息
- 维护成本高 — 需要额外的基础设施（向量数据库、向量化 API）
- 确定性差 — 你不确定 Agent 这次会检索到什么
替代方案（我们在用的）：
- SOUL.md + MEMORY.md = 确定性文档，每次会话都加载，100% 可靠
- 每日日志 = 短期记忆，只看今天的，不会被历史淹没
- 需要历史信息时 = 人类手动指定（“参考 memory/2026-02-08.md”）
详细的记忆管理配置： 见 实战菜谱 — 记忆管理与优化
💡 观点四：失败是最有价值的输入
Section titled “💡 观点四：失败是最有价值的输入”每次失败都应该变成永久机制。不是”下次注意”，是写成规则、脚本、或约束。
我们的流程：
- 失败发生
- 问 Agent：“发生了什么？走我看你的推理过程。”
- 识别根因（上下文丢失？工具用错？假设错误？）
- 实施预防：编辑 SOUL.md、添加记忆笔记、创建新检查
- 记录到
memory/improvements-log.md
硬规则：永远不只是重试。永远先加一个防护栏。
这叫防护栏工程 — 每个失败都让系统变得更强。几个月后，大多数常见失败模式都被规则覆盖了。Agent 变得越来越可靠，不是因为模型更好了，而是因为约束更完善了。
| 失败事件 | 根因 | 新增规则 |
|---|---|---|
| 部署坏产品给人类 | 没有 QA 环节 | ⛔ 质量关卡 — QA 必须通过 |
| 上下文满了卡死 | 没有监控上下文 | ⛔ 60% 自动压缩 |
| API 配额烧完 | 无限重试 | ⛔ 2 次失败后停止 |
| Agent 静默 6 小时 | 没有超时机制 | 30 分钟任务超时告警 |
| @mention 不工作 | 格式/配置错误 | 端到端通信测试清单 |
| SOUL.md 更新不生效 | 会话缓存 | 改配置后必须重启网关 |
三个月后的结果： SOUL.md 中约 30% 的规则是从失败中提炼出来的。这些规则的价值远超任何单个任务的产出。
👁️ 观点五：注意力是真正的瓶颈
Section titled “👁️ 观点五：注意力是真正的瓶颈”当你有 5 个 Agent 同时工作时，瓶颈不是计算力、不是 API 配额、不是模型能力。是你的注意力。
5 个 Agent 同时产出 → 你需要审查 5 份结果 → 每份需要判断质量 → 每个判断需要上下文 → 你的大脑是单线程的。
这就是为什么质量关卡不是浪费时间 — 它是注意力杠杆。QA 帮你做第一层审查，你只需要看通过/未通过和摘要。
更深层的启示： 随着 Agent 数量增加，你需要的不是更多 Agent，而是更好的过滤机制。信息要分级，只有真正需要人类决策的才到你面前。其他的，让 Agent 自己处理。
- COO 是唯一接口 — 人类只和 COO 对话，COO 处理所有分发和汇总
- Agent 不该提问 — 如果任务简报写得好，不需要追问。需要追问说明任务简报没写好
- 自动化决策 — P2/P3 任务，Agent 自己决定怎么执行。只有 P0/P1 需要人类输入
- 批量汇报 — 不要每完成一个任务就汇报。攒 3-5 个一起汇报
目标： 人类每天花 30 分钟管理 Agent，其余时间做只有人类能做的事（创意、策略、人际关系）。还没完全做到，但在接近。
⚓ 观点六：可靠 > 速度
Section titled “⚓ 观点六：可靠 > 速度”一个每次都给 80 分结果的系统，比一个有时 100 分有时 0 分的系统有价值得多。
前者你可以信任、可以委托、可以去睡觉。后者你必须盯着、随时准备救火。
这就是为什么我花了大量时间在质量保证、监控、约束上 — 看起来”慢”，但实际上是在建立信任。当你信任系统时，你才能真正放手。放手之后，系统的产出远超你一个人盯着它的时候。
类比： 你不会把钱交给一个有时候赚 100% 有时候赔光的基金经理。你会选那个稳定年化 15% 的。Agent 系统也一样。
这六个观点的共同主题：AI Agent 的价值不在于它多聪明，在于你能多信任它。 信任来自可靠性，可靠性来自约束和监控。
聪明是模型公司的事。你的工作是建系统，让聪明变得可靠。
如果你有不同的经验和观点 — 欢迎在 GitHub 上提议题讨论。多 Agent 系统还处于早期，需要更多真实案例来验证或推翻这些观点。