multi-agent-systems

多 Agent 系统

何时使用多 Agent 架构

多 Agent 系统会带来额外开销。每增加一个 Agent，就多一个潜在故障点、多一套需要维护的提示词，以及一个意外行为的来源。

多 Agent 系统消耗的 token 是单 Agent 方案的 3–10 倍，原因包括：

• 在 Agent 之间重复上下文
• Agent 之间的协调消息
• 为交接总结结果

从单 Agent 开始

设计良好的单 Agent 配备合适的工具后，能完成的任务远超预期。以下情况应使用单 Agent：

• 任务按顺序进行且依赖上下文
• 工具数量少于 15–20 个
• 并行化没有明显优势

多 Agent 优势明显的三种情况

1. 上下文污染——子任务会生成超过 1000 个 token，但大多数信息与主任务无关
2. 并行化——任务可以独立运行，并探索更大的搜索空间
3. 专业化——不同任务需要不同的工具、提示词或领域专业知识

决策框架

上下文保护模式

当子任务会生成大量上下文，但主任务只需要摘要时使用。

示例：客户支持

class OrderLookupAgent:
    def lookup_order(self, order_id: str) -> dict:
        messages = [{"role": "user", "content": f"Get essential details for order {order_id}"}]
        response = client.messages.create(
            model="claude-sonnet-4-5", max_tokens=1024,
            messages=messages, tools=[get_order_details_tool]
        )
        return extract_summary(response)  # Returns 50-100 tokens, not 2000+

class SupportAgent:
    def handle_issue(self, user_message: str):
        if needs_order_info(user_message):
            order_id = extract_order_id(user_message)
            order_summary = OrderLookupAgent().lookup_order(order_id)
            context = f"Order {order_id}: {order_summary['status']}, purchased {order_summary['date']}"
        # Main agent gets clean context

适用情况：

• 子任务会生成超过 1000 个 token，且大多数信息无关
• 子任务定义明确，且有清晰的提取标准
• 查找／检索操作需要先经过筛选才能使用

并行化模式

在探索更大的搜索空间或独立的研究方面时使用。

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def research_topic(query: str) -> dict:
    facets = await lead_agent.decompose_query(query)
    tasks = [research_subagent(facet) for facet in facets]
    results = await asyncio.gather(*tasks)
    return await lead_agent.synthesize(results)

async def research_subagent(facet: str) -> dict:
    messages = [{"role": "user", "content": f"Research: {facet}"}]
    response = await client.messages.create(
        model="claude-sonnet-4-5", max_tokens=4096,
        messages=messages, tools=[web_search, read_document]
    )
    return extract_findings(response)

优势： 更全面，而非更快。以更高的 token 成本覆盖更多内容。

专业化模式

工具集专业化

当 Agent 拥有 20 个以上工具、出现领域混淆或性能下降时，按领域拆分。

需要专业化的迹象：

1. 数量：20 个以上工具
2. 领域混淆：工具横跨互不相关的领域
3. 性能下降：新增工具影响现有任务的表现

系统提示词专业化

不同任务需要相互冲突的行为模式：

• 客户支持：富有同理心、耐心
• 代码审查：精准、严格
• 合规：严格遵循规则
• 头脑风暴：灵活创新

领域专业知识专业化

深厚的领域背景知识会让通才 Agent 不堪重负：

• 法律分析：判例法、监管框架
• 医学研究：临床试验方法

多平台集成示例

class CRMAgent:
    system_prompt = """You are a CRM specialist. You manage contacts,
    opportunities, and account records. Always verify record ownership
    before updates and maintain data integrity across related records."""
    tools = [crm_get_contacts, crm_create_opportunity]  # 8-10 CRM tools

class MarketingAgent:
    system_prompt = """You are a marketing automation specialist. You
    manage campaigns, lead scoring, and email sequences."""
    tools = [marketing_get_campaigns, marketing_create_lead]  # 8-10 tools

class OrchestratorAgent:
    def execute(self, user_request: str):
        response = client.messages.create(
            model="claude-sonnet-4-5", max_tokens=1024,
            system="""Route to appropriate specialist:
    - CRM: Contacts, opportunities, accounts, sales pipeline
    - Marketing: Campaigns, lead nurturing, email sequences""",
            messages=[{"role": "user", "content": user_request}],
            tools=[delegate_to_crm, delegate_to_marketing]
        )
        return response

以上下文为中心的拆分

以问题为中心（适得其反）： 按工作类型拆分（写作者、测试者、审查者）——会增加协调开销，并在交接时丢失上下文。

以上下文为中心（有效）： 负责某项功能的 Agent 也负责处理该功能的测试——因为它已经掌握必要的上下文。

有效的边界

• 独立的研究路径
• 具有清晰 API 契约的独立组件
• 黑盒验证

有问题的边界

• 同一项工作的连续阶段
• 紧密耦合的组件
• 需要共享状态的工作

验证子 Agent 模式

专门用于测试／验证主 Agent 工作的 Agent。此模式之所以有效，是因为验证所需的上下文传递很少。

class CodingAgent:
    def implement_feature(self, requirements: str) -> dict:
        response = client.messages.create(
            model="claude-sonnet-4-5", max_tokens=4096,
            messages=[{"role": "user", "content": f"Implement: {requirements}"}],
            tools=[read_file, write_file, list_directory]
        )
        return {"code": response.content, "files_changed": extract_files(response)}

class VerificationAgent:
    def verify_implementation(self, requirements: str, files_changed: list) -> dict:
        messages = [{"role": "user", "content": f"""
Requirements: {requirements}
Files changed: {files_changed}

Run the complete test suite and verify:
1. All existing tests pass
2. New functionality works as specified
3. No obvious errors or security issues

You MUST run: pytest --verbose
Only mark as PASSED if ALL tests pass with no failures.
"""}]
        response = client.messages.create(
            model="claude-sonnet-4-5", max_tokens=4096,
            messages=messages, tools=[run_tests, execute_code, read_file]
        )
        return {"passed": extract_pass_fail(response), "issues": extract_issues(response)}

缓解“过早宣布胜利”问题

验证者可能未经充分测试就标记为通过。预防方法：

• 具体标准：“运行完整测试套件”，而不是“确保它能正常工作”
• **全面检查：**测试多种场景和边界情况
• **负向测试：**确认应该失败的输入确实会失败
• 明确指示：“你必须运行完整测试套件”

后续步骤检查清单

在增加多 Agent 复杂性之前：

1. 确实存在约束（上下文限制、并行化或专业化需求）
2. 按上下文而非问题类型进行拆分
3. 设置明确的验证节点，供子 Agent 进行验证

从可行的最简单方案开始。只有在有证据支持时才增加复杂性。

参考资料

• 构建多 Agent 系统：何时以及如何使用
• 构建高效的 Agent
• 面向 AI Agent 的有效上下文工程
• 为 Agent 编写高效的工具