Claude Code 开发心智模型手册

// 模拟退火 Prompt 调优器
// 在 Claude Code 中运行：cc run optimize

interface PromptCandidate {
  content: string;
  score: number;
}

async function simulatedAnnealingOptimize(
  initialPrompt: string,
  evaluate: (p: string) => Promise<number>,
  iterations = 100
) {
  let current: PromptCandidate = {
    content: initialPrompt,
    score: await evaluate(initialPrompt)
  };
  let best = { ...current };
  let T = 1.0; // 初始温度

  for (let i = 0; i < iterations; i++) {
    T *= 0.97; // 降温速率

    // 高温：大变动；低温：小变动
    const candidate = T > 0.5
      ? await mutateStructure(current.content)  // 换段落/结构/persona
      : await mutatePhrasing(current.content);   // 只换措辞/词语

    const newScore = await evaluate(candidate);
    const delta = newScore - current.score;

    // 接受条件：更好 OR 概率性接受更差的
    if (delta > 0 || Math.random() < Math.exp(delta / T)) {
      current = { content: candidate, score: newScore };
    }

    if (current.score > best.score) best = { ...current };

    console.log(`T=${T.toFixed(2)} score=${newScore.toFixed(1)} best=${best.score.toFixed(1)}`);
  }

  return best;
}

## Prompt 调优协议（模拟退火模式）

### 当前处于哪个阶段？
- 高温期：新任务、新场景、效果还差。此时大改，不计较单次变差。
- 低温期：效果已经 7+/10，微调收敛。此时小改，不接受退步。

### 升温触发条件（任意一条）
- 同类改法连续 3 次无效
- 被同一个问题卡超过 2 天
- 输出得分长期在 6-7 震荡，无法突破

### 高温期允许的动作
- 完全换掉 persona / role 设定
- 增删整个 example 段落
- 改变输出格式（JSON vs Markdown vs 纯文本）
- 换 task framing（从"生成"改成"检查"）

### 低温期禁止的动作
- 同时改超过 2 处
- 接受比上一版得分低的版本

// ❌ 错误：伪装成并行的串行
const [text, image, timing] = await Promise.all([
  generateText(topic),
  generateImage(topic), // 实际上需要 text 来做风格对齐
  getBestTiming(topic),  // 实际上需要 text 来判断内容类型
]);
// → text/image/timing 之间有隐性依赖，并行会导致不一致

// ✅ 正确：先做正交测试，再决定并发结构
async function orchestrateContent(topic: string) {
  // Step 1：识别正交维度
  // 视觉风格模板 ⊥ 发布时间分析 ⊥ 历史数据提取 → 三者正交
  // 文案 → 依赖 topic（但不依赖其他 agent）→ 可独立
  
  const [styleTemplates, timingData, historicalPerf] = await Promise.all([
    fetchVisualStyles(),         // 不依赖文案
    analyzeBestPostTimes(),      // 不依赖文案
    fetchHistoricalPerformance(), // 不依赖文案
  ]);

  // Step 2：用上面的数据生成文案（现在可以做好风格对齐）
  const texts = await generateTexts(topic, {
    styleHints: styleTemplates,
    performanceSignals: historicalPerf,
  });

  // Step 3：文案确定后，图+排期可以再次并行
  const [images, schedule] = await Promise.all([
    generateImages(texts, styleTemplates),
    buildSchedule(texts, timingData),
  ]);

  return { texts, images, schedule };
}

## Multi-agent 任务拆解（傅里叶正交原则）

### 并行前必须通过正交测试
- 修改任务 A 的输入或实现，任务 B 的逻辑需要改变吗？
- 需要 → 不正交 → 必须串行
- 不需要 → 正交 → 可以并行

### 三类依赖关系
- 无依赖 → 第一批并行执行
- 单向依赖 → 拓扑排序，分批执行
- 双向依赖 → 不是两个任务，合并为一个

### 禁止
- 用 Promise.all 包所有 agent 就叫"并行"
- 忽视 agent 之间的隐性数据依赖（一个输出影响另一个质量）

// 主动探测 Context 相变点
async function findPhaseTransition(
  basePrompt: string,
  targetTask: string,
) {
  const results: { tokens: number; quality: number }[] = [];
  const tokenLevels = [1000, 2000, 4000, 8000, 16000, 32000];

  for (const tokens of tokenLevels) {
    const paddedPrompt = padToTokens(basePrompt, tokens);
    const quality = await evaluateQuality(paddedPrompt, targetTask);
    results.push({ tokens, quality });
    
    // 检测相变：质量突然下降超过 30%
    if (results.length > 1) {
      const prev = results[results.length - 2];
      const drop = (prev.quality - quality) / prev.quality;
      
      if (drop > 0.3) {
        console.log(`⚡ 相变点发现: ${tokens} tokens`);
        console.log(`   质量从 ${prev.quality.toFixed(1)} 跌至 ${quality.toFixed(1)}`);
        console.log(`   建议硬限制: ${prev.tokens} tokens`);
        break;
      }
    }
  }

  return results;
}

// 在系统中设置硬限制（不是软限制）
const CONTEXT_HARD_LIMIT = 6000; // 实测相变点 × 0.75

function safeContext(messages: Message[]): Message[] {
  const totalTokens = countTokens(messages);
  if (totalTokens <= CONTEXT_HARD_LIMIT) return messages;
  
  // 不是线性截断，是结构化压缩
  return [
    messages[0],                          // system prompt 保留
    ...summarizeMiddle(messages.slice(1, -4)), // 中间压缩
    ...messages.slice(-4),                  // 最近 4 条保留
  ];
}

## System 临界点管理（相变原则）

### 已知的 Claude Code 相变点（设为硬限制）
- Context 长度：超过 60% 窗口上限开始压缩，到 80% 必须截断
- Prompt 规则数：不超过 15 条，超出则拆分为子 agent
- Retry 次数：最多 3 次，超出换策略而不是继续重试
- 并发 Agent 数：超过 5 个必须分组，不能扁平并发

### 设置方式：硬限制，不是软警告
- 不是"快到了提示一下"，是"到了就截断/拒绝/换策略"
- 限制值 = 实测相变点 × 0.75（留安全边际）

### 禁止线性外推
- "再加几个 agent 应该没问题" → 协调成本是 O(n²)
- "context 再长一点应该还好" → 相变是突然发生的，不是线性的

class AgentQualityPID {
  private history: number[] = [];
  private kp = 0.5, ki = 0.1, kd = 0.3;
  private target = 8.5;

  record(score: number): CorrectiveAction {
    this.history.push(score);
    
    const e = this.target - score;                           // 当前误差
    const recentHistory = this.history.slice(-10);
    const I = recentHistory.reduce((s, v) => s + (this.target - v), 0);
    const D = this.history.length > 1
      ? score - this.history[this.history.length - 2]  // 正数=改善，负数=恶化
      : 0;
    
    const signal = this.kp * e + this.ki * I - this.kd * D;

    // 决策逻辑
    if (Math.abs(e) > 3) return {
      type: 'immediate',
      action: 'rewrite_user_prompt',    // P 大：立即修这次
      reason: `Score ${score} vs target ${this.target}`
    };

    if (I > 8) return {
      type: 'systemic',
      action: 'update_system_prompt',    // I 大：系统性问题
      reason: `Accumulated error: ${I.toFixed(1)}`
    };

    if (D < -1) return {
      type: 'preemptive',
      action: 'restructure_agent_pipeline', // D 负：趋势恶化
      reason: `Quality trending down: ${D.toFixed(2)}/call`
    };

    return { type: 'none', action: 'continue' };
  }
}

// 用法：在 agent 每次执行后记录
const pid = new AgentQualityPID();
const result = await agent.run(task);
const action = pid.record(await evaluate(result));
if (action.type !== 'none') handleCorrection(action);

## Agent 输出质量反馈（PID 模式）

### P 项（当前误差）— 立即修正
- 单次输出明显偏差时：在下一条消息里直接指出，让 Claude 重做这一步
- 不要积累问题，当场纠正

### I 项（历史积累）— 系统性修正
- 如果同类问题出现 3 次以上：更新本文件的相关规则
- 触发信号：反复提醒同一件事 → 说明 system prompt 有结构性漏洞

### D 项（变化趋势）— 预判式修正
- 输出质量在变差但还没崩溃时：主动重新描述任务背景和约束
- 不要等到质量已经很差再修正，提前干预成本最低

❌ 错误：试图控制每次输出（脆弱，过拟合）

你是一个社媒文案 agent。
每次输出必须：
- 第一句以数字或问题开头
- 第二句解释背景
- 第三句给出行动号召
- 结尾用 3 个 emoji
- 字数在 180-220 字之间
...（30条规则）

→ 对某类 topic 完全失控，规则相互冲突

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✅ 正确：定义吸引域边界（鲁棒，泛化性强）

## 引力中心（目标区域）
你生成的内容在语气上贴近真实用户，不像 AI，
在信息上聚焦有价值的洞察，不是空泛的感叹。

## 排斥边界（绝对不出现）
- 不使用"赋能/赋权/生态"等营销黑话
- 不使用 5 个以上 emoji（视觉噪音）
- 不承诺具体数字收益（合规风险）
- 不提及竞争产品名称
- 不超过 280 字

## 自由区间（故意不规定）
- 开头方式：自由，根据内容选择最自然的
- 句子数量：自由，够清晰就行
- 话题角度：自由，选最有趣的切入点

// 吸引域验证器：检查输出是否在边界内
interface AttractorBoundary {
  hardRules: {               // 排斥边界：违反 = 重新生成
    maxLength: number;
    forbiddenPatterns: RegExp[];
    requiredElements?: string[];
  };
  softGuidelines: string[];  // 引力中心：写在 prompt 里，不做硬检查
}

const xerpaAgentBoundary: AttractorBoundary = {
  hardRules: {
    maxLength: 280,
    forbiddenPatterns: [
      /赋能|赋权|生态/g,
      /保证.*%收益|承诺.*倍/g,
      /(competitor1|competitor2)/gi,
      /[^\S\r\n]{2,}/g,  // 多余空格
    ],
  },
  softGuidelines: [
    '语气真实，不像营销文案',
    '优先用具体数据替代形容词',
  ],
};

async function generateWithBoundary(
  prompt: string,
  boundary: AttractorBoundary,
  maxRetries = 3
): Promise<string> {
  for (let i = 0; i < maxRetries; i++) {
    const output = await callClaude(prompt);
    const violation = checkBoundary(output, boundary.hardRules);
    
    if (!violation) return output; // 在吸引域内
    
    // 把违规信息加回 prompt，让模型自我修正
    prompt += `\n\n[修正提示] 上次违规: ${violation}，请重新生成`;
  }
  throw new Error('无法在边界内生成合格内容');
}

## System Prompt 结构（吸引域三层模板）

### 第一层：引力中心（写在 prompt 里，不做硬检查）
- 目标语气/风格方向
- 好的输出"看起来像什么"

### 第二层：排斥边界（硬约束，程序化检查 or 明确列出）
- 禁止词汇：[根据业务填写，如"赋能/生态/赋权"]
- 禁止格式：超过 N 个 emoji，超过 X 字
- 禁止内容：具体数字承诺、竞品名称

### 第三层：自由区间（故意留白，不规定）
- 开头方式：自由
- 句子数量：够清晰就行
- 角度选择：选最有趣的

### 禁止
- 超过 15 条规则的 system prompt（触发相变）
- "必须出现什么"比"绝对不出现什么"更多

// 用于在 Claude Code 中快速诊断 prompt 质量
// 运行：cc run check-entropy --prompt="your prompt"

import { Claude } from '@anthropic-ai/sdk';

async function diagnosePromptEntropy(
  prompt: string,
  n = 5
): Promise<EntropDiagnosis> {
  const client = new Claude();
  
  // 并行跑 n 次
  const outputs = await Promise.all(
    Array.from({ length: n }, () =>
      client.messages.create({
        model: 'claude-opus-4-5',
        max_tokens: 500,
        messages: [{ role: 'user', content: prompt }],
        temperature: 1.0,  // 使用默认温度，不要降温
      })
    )
  );
  
  const texts = outputs.map(o => o.content[0].text);

  // 简单结构相似度：比较段落数、总字数、关键词
  const structures = texts.map(t => ({
    paragraphs: t.split('\n\n').length,
    wordCount: t.split(' ').length,
    hasCode: t.includes('```'),
    hasNumberedList: /^\d+\./m.test(t),
  }));

  // 计算结构一致性（越接近 1 = 低熵）
  const structuralConsistency = calcConsistency(structures);
  
  return {
    sampleOutputs: texts,
    structuralConsistency,         // 0-1，越高越一致
    entropyLevel: structuralConsistency > 0.8 ? 'low'
                : structuralConsistency > 0.5 ? 'medium'
                : 'high',
    diagnosis: diagnose(structures, texts),
  };
}

// 在 Claude Code 工作流中:
// cc run diagnose-entropy → 识别问题 → cc run fix-prompt → 再诊断

## Prompt 质量诊断（香农熵方法）

### 诊断信号（不需要代码，脑内判断）
- 同一 prompt 跑 3 次，结构都不一样 → 极高熵，需要重写
- 结构相同但内容切角差异大 → 高熵，加 few-shot examples
- 细节略有不同，结构一致 → 正常，可接受
- 几乎完全相同 → 低熵，如需多样性则放松约束

### 降熵工具（按效果排序）
1. 指定输出格式（JSON / 固定段落结构）
2. 加 2-3 个 few-shot examples（最有效）
3. 指定输出长度范围（字数上限）
4. 指定视角/角色

### 触发降熵操作的条件
- 同一 prompt 连续 3 次输出质量差异超过 30%
- 输出语言不稳定（时中时英）
- 每次结构都需要人工调整

// 三条产品线的帕累托配置
const paretoConfigs = {
  // 支付确认：速度 > 质量 > 成本
  'payment-confirm': {
    model: 'claude-haiku-4-5',
    concurrency: 10,
    maxRetries: 1,          // 宁可失败，不能超时
    timeoutMs: 2000,
    streaming: true,
    tradeoff: 'speed=10, quality=6, cost=9',
  },
  
  // 内容生成：质量 > 成本 > 速度
  'xerpa-content': {
    model: 'claude-sonnet-4-6',
    concurrency: 3,
    maxRetries: 3,          // 允许重试，追求质量
    timeoutMs: 30000,
    streaming: false,
    tradeoff: 'speed=4, quality=9, cost=5',
  },
  
  // 数据分析：成本 > 质量 > 速度
  'data-analytics': {
    model: 'claude-haiku-4-5',
    concurrency: 1,          // 串行，省 token
    maxRetries: 2,
    timeoutMs: 60000,        // 允许慢
    cacheEnabled: true,     // 激进缓存
    tradeoff: 'speed=2, quality=7, cost=10',
  },
};

// 关键：每条业务线明确自己在哪个前沿点，不混用
function getAgentConfig(productLine: string) {
  const config = paretoConfigs[productLine];
  if (!config) throw new Error(
    `Unknown product line: ${productLine}. Must explicitly define tradeoffs first.`
  );
  return config;
}

// 帕累托支配：如果 A 在所有维度都 >= B，则 B 被支配（B 是次优的）
function isDominated(
  candidate: Config,
  others: Config[],
  objectives: (keyof Config)[]
): boolean {
  return others.some(other =>
    objectives.every(o => other[o] >= candidate[o]) &&
    objectives.some(o => other[o] > candidate[o])
  );
}

// 使用：淘汰被支配的配置
const paretoFront = configs.filter(c =>
  !isDominated(c, configs, ['speed', 'quality', 'cost'])
);
// 剩下的才值得讨论，它们才是真正的 tradeoff 选择

## 架构决策原则（帕累托约束）

### 本项目的优先级（按顺序）
1. 正确性 > 速度 > 成本
   - 宁可慢，不要错
   - 宁可贵，不要用户不信任

### 禁止"同时优化三个维度"
- 每次架构讨论必须明确：这次牺牲哪个
- 如果有方案声称"全都能优化"，必须质疑

### agent 配置时的 tradeoff 模板
- 高质量场景（对外输出）：quality first，允许慢 3x、贵 5x
- 高频内部场景（数据处理）：speed first，允许质量 -20%
- 实验/原型阶段：cost first，允许不稳定

// 贝叶斯能力探测：用小样本测试更新对 Claude 的能力判断
class CapabilityBayes {
  private prior: number;      // 初始估计 0-1
  private successes = 0;
  private trials = 0;

  constructor(prior = 0.5) {
    this.prior = prior;
  }

  update(success: boolean): void {
    this.trials++;
    if (success) this.successes++;
  }

  posterior(): number {
    const alpha = this.prior * 10 + this.successes;
    const beta = (1 - this.prior) * 10 + (this.trials - this.successes);
    return alpha / (alpha + beta);
  }

  decision(): 'trust' | 'uncertain' | 'fallback' {
    const p = this.posterior();
    if (p > 0.8) return 'trust';
    if (p > 0.4) return 'uncertain';
    return 'fallback';
  }
}

const probe = new CapabilityBayes(0.6); // 先验 60%

for (const testCase of testCases) {
  const result = await claudeAgent.run(testCase);
  probe.update(evaluate(result, testCase.expected));
  console.log(`后验: ${(probe.posterior() * 100).toFixed(0)}% | 决策: ${probe.decision()}`);
  if (probe.decision() !== 'uncertain') break;
}

## Claude 能力评估规则（贝叶斯原则）

### 禁止单次定论
- 1 次失败 ≠ "Claude 做不到"
- 1 次成功 ≠ "Claude 可以可靠依赖"
- 需要 3-5 次测试，再决策

### 评估触发条件
- 新类型任务：先跑 3 个样本测试，再集成到主流程
- 质量波动大：增加测试次数，确认是偶然还是系统性

### 决策阈值
- >80% 成功率（3+ 次测试）→ 可以依赖
- 40-80%：继续测，或加 retry 逻辑
- <40% → 换策略：改 prompt、换模型、或人工介入

class KalmanQualityTracker {
  private estimate: number;
  private uncertainty: number;
  private processNoise: number;
  private observationNoise: number;

  constructor(initialEstimate = 7) {
    this.estimate = initialEstimate;
    this.uncertainty = 1;
    this.processNoise = 0.1;
    this.observationNoise = 2;
  }

  update(observed: number) {
    const predictedUncertainty = this.uncertainty + this.processNoise;
    const K = predictedUncertainty / (predictedUncertainty + this.observationNoise);

    const prevEstimate = this.estimate;
    this.estimate = this.estimate + K * (observed - this.estimate);
    this.uncertainty = (1 - K) * predictedUncertainty;

    const deviation = Math.abs(observed - prevEstimate);
    const trend = this.estimate - prevEstimate;

    return {
      estimate: Math.round(this.estimate * 10) / 10,
      kalmanGain: Math.round(K * 100) / 100,
      status: deviation > 3 && Math.abs(trend) < 0.5 ? 'noise'
            : trend < -0.3 ? 'degrading'
            : 'normal',
    };
  }
}

## Agent 质量跟踪规则（卡尔曼滤波原则）

### 用移动平均代替单次评分
- 不用单次分数触发告警
- 用最近 5 次的加权平均（近期权重更高）判断趋势

### 区分噪声和真实退化
- 单次分数偏离历史均值 >3 → 大概率是噪声，观察下一次
- 连续 3 次低于历史均值 >1 → 真实退化，触发 I 项修正

### 响应阈值（防止过度响应）
- 不要因为一次差的输出修改 system prompt
- 要因为"移动平均持续下降超过 1 分"才修改
- 更新 system prompt 前，先判断是任务难度问题还是系统问题

// 错误：各 agent 独立定义"成功"标准 → 对抗均衡
const writerPrompt = `写一篇高质量文章，要通过审核`
const reviewerPrompt = `严格审核文章，找出所有问题`
// 结果：writer 写防御性内容，reviewer 挑越来越细的毛病

// 正确：共享 rubric，建立协调均衡
const SHARED_RUBRIC = {
  clarity:     { weight: 0.3, desc: '逻辑清晰，论点有层次' },
  accuracy:    { weight: 0.3, desc: '事实准确，代码可运行' },
  actionable:  { weight: 0.2, desc: '读者可以立即采取行动' },
  conciseness: { weight: 0.2, desc: '没有多余的话' },
}

const writerPrompt = `
  写一篇满足以下标准的文章：
  ${JSON.stringify(SHARED_RUBRIC)}
  每个维度目标分：≥7/10
`

const reviewerPrompt = `
  按以下标准评分，给出每个维度的分数和具体改进建议：
  ${JSON.stringify(SHARED_RUBRIC)}
  目标：帮助 writer 达到每项 ≥7/10，不是找茬
`

async function coordinatedGeneration(topic: string) {
  let draft = await writer.generate(topic, writerPrompt)

  for (let i = 0; i < 3; i++) {
    const review = await reviewer.evaluate(draft, reviewerPrompt)
    if (review.scores.every(s => s.score >= 7)) break
    draft = await writer.revise(draft, review.feedback)
  }

  return draft
}

## 多 Agent 系统设计规则（纳什均衡原则）

### 共享评分标准
- 所有参与同一任务的 agent 必须使用相同的 rubric
- rubric 在系统提示开头声明，所有 agent 都能看到

### 禁止对抗性指标
- 不允许用"找到问题数量"衡量 critic agent 的效果
- 不允许用"通过审核率"衡量 writer agent 的效果
- 只用"最终输出质量"作为整体系统指标

### 收敛条件
- 每个迭代循环必须有明确的终止条件（分数阈值或最大轮次）
- 若达到最大轮次仍未收敛，升级为人工介入，不要静默降级

const stabilityTests = [
  {
    name: '短文本扰动',
    perturbations: ['ok', '.', ''],
    isStable: (out: string) => out.length < 200,
  },
  {
    name: '超长输入扰动',
    perturbations: ['x'.repeat(50000)],
    isStable: (out: string) => !out.includes('error'),
  },
]

for (const test of stabilityTests) {
  for (const p of test.perturbations) {
    const out = await agent.run(p)
    if (!test.isStable(out))
      console.warn(`⚠ 不稳定：${test.name}`)
  }
}

## Agent 鲁棒性规则（李雅普诺夫原则）

### 必须处理的边界输入
- 空输入：返回明确错误，不要静默失败
- 超长输入（>预期 5 倍）：截断 + 告知，不要崩溃
- 非预期语言：检测后明确告知，不要乱猜

### 稳定域定义
- 每个 agent 的 system prompt 开头必须声明"本 agent 处理什么类型的输入"
- 超出稳定域的输入应触发 fallback，不是随机输出

### 发散预防
- 不允许 agent 在单次对话中无限追加内容（设置最大 token 限制）
- 不允许 agent 自我引用上一轮输出作为新输入（防止雪球效应）

// 低匹配（常见写法）
"帮我优化这段代码"

// 高匹配（对齐模型接收方式）
`目标：减少数据库查询次数（不是重构代码结构）
约束：不改函数签名，不引入新依赖
输出：① 问题诊断 ② 具体改动 ③ 改后代码
不需要：测试代码，基础知识解释`

// 现在模型知道：做什么、不做什么、输出什么格式

## Prompt 设计规则（阻抗匹配原则）

### 必须包含的元素
- 任务目标：一句话说清楚要做什么
- 排除项：明确说"不需要做什么"（减少过度脑补）
- 输出格式：提供一个示例

### 禁止的模式
- 不用"帮我优化/改进/完善"等模糊动词
- 不在单次请求中混合多个不同类型的任务
- 不用"尽量/最好/如果可以"（会降低执行优先级）

P(Xₙ₊₁ = s | X₁, X₂, ..., Xₙ) = P(Xₙ₊₁ = s | Xₙ)

下一个状态只取决于当前状态，与历史无关。

Transformer 理论上能看到所有历史（全局 attention），但实践中：远处的 token attention 权重更低，早期指令会被稀释。Context window 是硬截断。这意味着你的对话历史越长，早期的约束越容易被"遗忘"。

# 显式状态转换，不依赖对话历史
class AgentStateMachine:
    states = ["IDLE", "PLANNING", "EXECUTING", "VERIFYING", "DONE"]

    def transition(self, current_state, event):
        transitions = {
            ("IDLE", "task_received"): "PLANNING",
            ("PLANNING", "plan_approved"): "EXECUTING",
            ("EXECUTING", "task_done"): "VERIFYING",
            ("EXECUTING", "error"): "PLANNING",  # 重新规划
            ("VERIFYING", "passed"): "DONE",
        }
        return transitions.get((current_state, event), current_state)

修复：把核心约束放在 CLAUDE.md（每次都重新加载），或在长对话中定期用 /compact 保留关键约束。

系统整体表现出其组成部分所没有的性质。蚁群无中央指挥却能建造复杂巢穴；神经元不会"思考"但大脑会。LLM 超过某规模阈值后，能力出现非线性跳跃。

# 单 Agent 三重角色——互相干扰
result = agent.plan_and_execute_and_verify(task)

# 分离角色——涌现出制衡效果
plan = planning_agent.run(task)
execution = execution_agent.run(plan)
verdict = verification_agent.run(task, execution)  # 独立视角

原则：把涌现当惊喜，把显式设计当基础。关键任务用明确约束，不靠能力涌现。