核心设计原则

3.1 原则一：Separation of Concerns（关注点分离）

Agent 的角色应该清晰定义，避免”万能 Agent”：

❌ 错误做法：
┌─────────────────────────────────┐
│  "超级 Agent"                    │
│  - 理解用户意图                  │
│  - 规划任务                      │
│  - 执行操作                      │
│  - 验证结果                      │
│  - 处理错误                      │
│  - 生成报告                      │
│  - 发送通知                      │
│  ... (无限扩展)                  │
└─────────────────────────────────┘

✅ 正确做法：
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  Intent      │   │  Planner     │   │  Executor    │
│  Classifier  │ → │              │ → │              │
└──────────────┘   └──────────────┘   └──────────────┘
                           ↓
                  ┌──────────────┐   ┌──────────────┐
                  │  Validator   │   │  Reporter    │
                  │              │ → │              │
                  └──────────────┘   └──────────────┘

3.2 原则二：Stateless by Default（默认无状态）

关键洞察: LLM 上下文窗口不是数据库，不应该用于持久化状态。

┌─────────────────────────────────────────────────────────────┐
│  错误模式：在上下文中累积状态                                │
├─────────────────────────────────────────────────────────────┤
│  User: "帮我规划一个旅行"                                    │
│  Agent: [在上下文中维护所有旅行细节...]                       │
│  User: "修改第三天的行程"                                   │
│  Agent: [需要重新读取整个上下文...]                           │
│  User: "加入另一个城市"                                      │
│  Agent: [上下文爆炸，超出窗口限制]                           │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  正确模式：外部状态管理                                      │
├─────────────────────────────────────────────────────────────┤
│  User: "帮我规划一个旅行"                                    │
│  Agent: [创建结构化状态 → 存入数据库/文件]                    │
│  User: "修改第三天的行程"                                   │
│  Agent: [读取状态 → 修改 → 写回]                             │
│  User: "加入另一个城市"                                      │
│  Agent: [增量更新，上下文保持精简]                           │
└─────────────────────────────────────────────────────────────┘

3.3 原则三：Explicit Boundaries（显式边界）

每个 Agent、每个工具、每个 Skill 都应该有清晰的职责边界：

组件	应该做	不应该做
Intent Classifier	分类用户意图	执行具体任务
Planner	分解任务为步骤	直接调用工具
Executor	执行单个步骤	决定下一步做什么
Validator	检查结果质量	修改输出

3.4 原则四：Fail Fast, Recover Faster（快速失败，快速恢复）

传统思维: "让系统尽量不失败"
Agent 思维: "系统一定会失败，关键是如何快速恢复"

┌─────────────────────────────────────────────────────────────┐
│  失败处理层次                                                │
├─────────────────────────────────────────────────────────────┤
│  Level 1: 工具调用失败 → 重试 + fallback                     │
│  Level 2: Agent 执行失败 → 汇报 + 部分结果                   │
│  Level 3: 编排失败 → 回滚 + 恢复到上一个稳定状态              │
│  Level 4: 系统失败 → 降级服务 + 人工介入                     │
└─────────────────────────────────────────────────────────────┘

3.5 原则五：Observability First（可观测性优先）

从 Day 1 就应该设计可观测性：

必须追踪的信号:
├── 输入层面
│   ├── 用户意图分布
│   ├── 输入长度/复杂度
│   └── 会话上下文大小
├── 执行层面
│   ├── 工具调用频率
│   ├── 工具调用成功率
│   ├── Agent 间消息传递
│   └── 步骤执行时间
├── 输出层面
│   ├── 输出长度
│   ├── 用户满意度信号
│   ├── 人工介入率
│   └── 错误类型分布
└── 成本层面
    ├── Token 消耗
    ├── API 调用次数
    └── 端到端延迟

---