agent-orchestration-improve-agent

Agent 性能优化工作流

通过性能分析、提示词工程和持续迭代，系统地改进现有 Agent。

[扩展思考：Agent 优化需要采用数据驱动的方法，结合性能指标、用户反馈分析和先进的提示词工程技术。成功取决于系统化评估、有针对性的改进，以及严格测试并具备回滚能力，以确保生产环境安全。]

适用场景

• 提升现有 Agent 的性能或可靠性
• 分析故障模式、提示词质量或工具使用情况
• 运行结构化 A/B 测试或评估套件
• 设计 Agent 的迭代优化工作流

不适用场景

• 从零开始构建全新的 Agent
• 没有可用的指标、反馈或测试用例
• 任务与 Agent 性能或提示词质量无关

说明

1. 建立基准指标并收集有代表性的示例。
2. 找出故障模式，并优先修复影响最大的部分。
3. 通过提示词和工作流改进，实现可衡量的目标。
4. 通过测试进行验证，并分阶段受控推出变更。

执行边界

不要仅仅因为某个阶段提到了托管评估、委派、向团队发送消息、配置定期报告或部署，就执行这些操作。遵循用户现有的授权和实际宿主工作流。对跟踪记录保密并进行脱敏，限制成本和步骤，隔离候选变更，并要求执行受支持的精确版本检查。parallel-test-runner 和具名 Agent 角色并非随附工具；请使用真实的测试框架，或说明这一缺口。

安全

• 避免在未经回归测试的情况下部署提示词变更。
• 如果质量或安全指标退化，请迅速回滚。

阶段 1：性能分析与基准指标

分析提供的跟踪记录和可用指标。下列具名角色仅为可选角色，并非已安装的可执行程序，也不代表获得了委派权限。

1.1 收集性能数据

Use: context-manager
Task: analyze the authorized trace window using actual available tools
No analyze-agent-performance command is bundled.

收集以下指标：

• 任务完成率（成功与失败的任务）
• 回答准确性和事实正确性
• 工具使用效率（工具是否正确、调用频率）
• 平均响应时间和 Token 消耗量
• 用户满意度指标（修正、重试）
• 幻觉事件和错误模式

1.2 用户反馈模式分析

识别用户交互中的重复模式：

• 修正模式：用户反复修改输出的情况
• 澄清请求：常见的歧义领域
• 任务放弃：用户放弃任务的环节
• 后续问题：回答不完整的迹象
• 正面反馈：值得保留的成功模式

1.3 故障模式分类

按根本原因对故障进行分类：

• 指令理解错误：角色或任务混淆
• 输出格式错误：结构或格式问题
• 上下文丢失：长对话导致的性能退化
• 工具误用：工具选择错误或效率低下
• 约束违反：违反安全或业务规则
• 边缘情况处理：异常输入场景

1.4 基准性能报告

生成定量基准指标：

Performance Baseline:
- Task Success Rate: [X%]
- Average Corrections per Task: [Y]
- Tool Call Efficiency: [Z%]
- User Satisfaction Score: [1-10]
- Average Response Latency: [Xms]
- Token Efficiency Ratio: [X:Y]

阶段 2：提示词工程改进

使用 prompt-engineer agent 应用先进的提示词优化技术。

2.1 思维链增强

实施结构化推理模式：

Use: prompt-engineer
Technique: chain-of-thought-optimization

• 添加明确的推理步骤：“让我们按步骤来处理……”
• 加入自我验证检查点：“继续之前，请确认……”
• 对复杂任务实施递归分解
• 收集简明的决策说明和可观察的工具跟踪记录，而非隐藏的思维链

2.2 少样本示例优化

从成功交互中筛选高质量示例：

• 选择多样化的示例，涵盖常见用例
• 纳入边界情况，尤其是之前失败过的情况
• 展示正例和反例，并附上说明
• 按由简单到复杂的顺序排列示例
• 为示例添加注释，标出关键决策点

示例结构：

Good Example:
Input: [User request]
Evidence: [Concise rationale and observable checks]
Output: [Successful response]
Why this works: [Key success factors]

Bad Example:
Input: [Similar request]
Output: [Failed response]
Why this fails: [Specific issues]
Correct approach: [Fixed version]

2.3 角色定义优化

强化 Agent 身份和能力：

• 核心目的：清晰、简洁的一句话使命
• 专业领域：具体的知识领域
• 行为特征：个性和交互风格
• 工具熟练度：可用工具及其使用时机
• 限制：Agent 不应做什么
• 成功标准：衡量任务完成情况的方法

2.4 宪法式 AI 集成

实现自我纠正机制：

Constitutional Principles:
1. Verify factual accuracy before responding
2. Self-check for potential biases or harmful content
3. Validate output format matches requirements
4. Ensure response completeness
5. Maintain consistency with previous responses

添加批判与修订循环：

• 生成初始响应
• 根据原则进行自我批判
• 检测到问题时自动修订
• 输出前进行最终验证

2.5 输出格式调整

优化响应结构：

• 针对常见任务使用结构化模板
• 根据复杂度动态调整格式
• 对详细信息采用渐进式披露
• 优化 Markdown，提升可读性
• 格式化代码块并添加语法高亮
• 使用表格和列表展示数据

第 3 阶段：测试与验证

采用 A/B 对比的综合测试框架。

3.1 测试套件开发

创建有代表性的测试场景：

Test Categories:
1. Golden path scenarios (common successful cases)
2. Previously failed tasks (regression testing)
3. Edge cases and corner scenarios
4. Stress tests (complex, multi-step tasks)
5. Adversarial inputs (potential breaking points)
6. Cross-domain tasks (combining capabilities)

3.2 A/B 测试框架

比较原始 Agent 与改进后的 Agent：

Use: parallel-test-runner
Config:
  - Agent A: Original version
  - Agent B: Improved version
  - Test set: 100 representative tasks
  - Metrics: Success rate, speed, token usage
  - Evaluation: Blind human review + automated scoring

统计显著性检验：

• 根据基线方差/比率、最小可检测效应和预期检验功效确定样本量；100 个任务仅为示例数据集规模
• 预先设定 alpha、置信区间、配对/随机化设计和多重比较策略；p < 0.05 并不表示某项主张有 95% 的概率为真
• 计算效应量（Cohen's d）
• 对未来测试进行功效分析

3.3 评估指标

综合评分框架：

任务级指标：

• 完成率（二元成功/失败）
• 正确性评分（准确率 0–100%）
• 效率评分（实际步骤数与最优步骤数的比较）
• 工具使用是否恰当
• 响应的相关性和完整性

质量指标：

• 幻觉率（每次响应中的事实错误数）
• 一致性评分（与先前响应的吻合程度）
• 格式合规性（是否符合指定结构）
• 安全评分（是否遵守限制）
• 用户满意度预测

性能指标：

• 响应延迟（生成首个 token 的时间）
• 总生成时间
• token 消耗量（输入 + 输出）
• 每项任务的成本（API 使用费用）
• 内存/上下文效率

3.4 人工评估流程

结构化的人工审查流程：

• 盲评（评估者不知道版本）
• 使用标准化评分表，明确评估标准
• 每个样本由多位评估者评估（评估者间信度）
• 收集定性反馈
• 偏好排序（A 与 B 对比）

第 4 阶段：版本控制与部署

通过监控和回滚能力，安全地逐步上线。

4.1 版本管理

系统化的版本策略：

Version Format: agent-name-v[MAJOR].[MINOR].[PATCH]
Example: customer-support-v2.3.1

MAJOR: Significant capability changes
MINOR: Prompt improvements, new examples
PATCH: Bug fixes, minor adjustments

维护版本历史：

• 基于 Git 的提示词存储
• 记录改进详情的变更日志
• 各版本的性能指标
• 记录回滚流程

4.2 分阶段发布

渐进式部署策略：

1. Alpha 测试：内部团队验证（5% 流量）
2. Beta 测试：选定用户（20% 流量）
3. Canary 发布：逐步增加（20% → 50% → 100%）
4. 全面部署：达到成功标准后进行
5. 监控期：观察 7 天

4.3 回滚流程

快速恢复机制：

Rollback Triggers:
- Success rate drops >10% from baseline
- Critical errors increase >5%
- User complaints spike
- Cost per task increases >20%
- Safety violations detected

Rollback Process:
1. Detect issue via monitoring
2. Alert team immediately
3. Switch to previous stable version
4. Analyze root cause
5. Fix and re-test before retry

4.4 持续监控

实时跟踪性能：

• 包含关键指标的仪表板
• 异常检测警报
• 收集用户反馈
• 自动化回归测试
• 每周性能报告

成功标准

以下是示例性目标，并非普遍适用的成功条件。应在测试前选定实际标准，区分相对变化与百分点，并报告不确定性：

• 任务成功率提升 ≥15%
• 用户纠正次数减少 ≥25%
• 安全违规行为没有增加
• 响应时间保持在基线的 10% 以内
• 每项任务的成本增幅不超过 5%
• 正面用户反馈增加

部署后审查

投入生产使用 30 天后：

1. 分析累积的性能数据
2. 与基线和目标进行比较
3. 识别新的改进机会
4. 记录经验教训
5. 规划下一轮优化

持续改进周期

建立定期改进节奏：

• 每周：监控指标并收集反馈
• 每月：分析模式并规划改进
• 每季度：发布具备新功能的主要版本更新
• 每年：进行战略审查并更新架构

请记住：Agent 优化是一个迭代过程。每个周期都以前期经验为基础，在保持稳定性和安全性的同时逐步提升性能。

限制

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少必要输入、权限、安全边界或成功标准，请停止并请求澄清。