用于构建多智能体系统的智能体架构模式——人类—智能体交互模式

在前几章中，我们建立了让智能体系统实现协同（coordinated） 、合规（compliant）与鲁棒（robust） 的架构模式。一个可靠且透明的系统，是最关键关系的必要基础：也就是 AI 智能体与其人类用户之间的关系。要让智能体系统超越后台自动化，真正增强人类知识工作者（knowledge workers），它与人的交互必须直观、可信且有效。

本章专门讨论治理这一关键接口的模式。为了让这些模式尽可能可操作（actionable），我们将采用一种"旅行前先看地图（map before the journey） "的方法。在详细讲解每一个模式之前，我们会先给出一份战略性的实施指南。该指南引入了一个成熟度模型，把这些模式组织成一条清晰、渐进的路线图：从简单的事务型机器人，到主动、协作型伙伴。

先理解整体图景，你就会具备足够的上下文来把握每个具体模式应放在什么位置，以及它为何对构建既强大又安全、可用，并最终能被目标用户采纳（adopted）的智能体系统至关重要。

在本章中，我们将覆盖以下主题：

人类---智能体交互模式的实施战略指南
Agent Calls Human（Human-in-the-Loop Escalation）
Human Delegates to Agent
Human Calls Agent
Agent Delegates to Agent
Agent Calls Proxy Agent

人类---智能体交互模式的实施战略指南（Strategic guide to implementing human-agent interaction patterns）

了解单个的人类---智能体交互模式只是第一步。下一步，是以战略方式应用它们来构建既强大又可信的系统。并不需要、甚至也不建议一次性把所有模式都实现。正确做法是：随着系统复杂度提升，以及对更复杂协作工作流的需求增长，逐步采用这些模式。

人类---智能体交互的分级（Levels of human-agent interaction）

面对一套完整的模式语言，一个常见问题是："我该从哪里开始？"一次性实现所有模式不仅不现实，而且对早期阶段的系统往往也没必要。成功的关键在于渐进式采用（progressive adoption） ：先打牢简单、可靠交互的基础，然后随着智能体系统在复杂性与责任范围上的增长，再叠加更高级的自治与协作层。

下面的成熟度模型为这一旅程提供了战略路线图。它把人类---智能体交互模式组织成五个不同层级，从基础的事务型机器人逐步演进为主动、协作型数字助理。通过识别你当前系统的需求与未来目标，你可以使用该模型在恰当时间选择并实现恰当的一组模式。

Level	Capabilities	Enabled patterns	Summary
1. Transactional systems	直接、单轮交互	Human Calls Agent	系统充当一个响应式工具，以速度与准确性处理简单、定义清晰的命令与查询
2. Assisted automation	基础委派与升级（escalation）	Human Delegates to Agent；Agent Calls Human	系统能承担简单的多步骤任务，但也知道自身边界，能在遇到歧义或需要批准时可靠地升级到人类
3. Collaborative systems	内部多智能体工作流	Agent Delegates to Agent	系统可通过编排一组内部专家智能体来解决复杂问题，并对用户隐藏内部协作细节
4. Secure and interoperable ecosystems	安全的外部交互	Agent Calls Proxy Agent	系统能够安全且可靠地与第三方系统交互，实现跨企业协作
5. Proactive and personalized partners	具备预判能力、上下文感知的协作	所有模式 + 长期记忆（long-term memory）	系统从工具演进为伙伴，学习用户偏好，并主动协助完成复杂目标

Table 8.1 -- A maturity model for adopting human-agent interaction patterns

这个成熟度模型回答了"何时（when） "（采用顺序的指导）。但要有效实现这些模式，我们还需要理解"何处（where） "（它们如何嵌入生产级系统的不同功能层）。下面的架构提供了一个把这些模式集成到统一整体中的实用蓝图。

系统集成架构：这些模式如何协同（System integration architecture: how the patterns work together）

该架构展示了在完整应用中，如何把这些模式组织到不同功能层级中。这些层保证了清晰的关注点分离：从面向用户的界面，到对外部通信的安全处理：

用户界面（UI）层：这是人类用户的直接接触点。所有交互都从这里发起。
- 启用模式：Human Calls Agent（直接命令）；Human Delegates to Agent（复杂目标）
编排与主智能体层（Orchestration and primary agent tier） ：该层承载用户直接交互的主智能体（例如 TravelPlannerAgent、ResearchAssistantAgent）。它负责高层规划、分解用户目标，并管理整体工作流。
- 启用模式：接收被委派任务，并向专家层发起 Agent Delegates to Agent 调用；同时也负责通过 Agent Calls Human 模式处理升级（escalations）
专家与执行智能体层（Specialist and worker agent tier） ：该层包含执行核心业务逻辑的功能型、细粒度智能体（例如 FlightBookingAgent、NewsSentimentAgent）。
- 启用模式：执行通过 Agent Delegates to Agent 模式接收的任务，并在必要时通过安全层发起外部请求
安全与代理层（Security and proxy tier） ：这是一个专门且隔离的层，负责所有对外通信。
- 启用模式：承载 proxy agents，作为通往第三方 API 或其他企业系统的安全网关，通过 Agent Calls Proxy Agent 模式进行交互；这一层是唯一持有凭证与具备对外交互逻辑的层

为了看看这些模式在真实世界场景中如何连接，我们以一个常见企业任务为例：预订企业差旅。

模式链路在实践中的串联：企业差旅预订示例（Pattern chaining in practice: a corporate travel booking example）

该示例展示了不同交互与委派模式如何串联起来以完成一个复杂用户目标，并在触及系统能力边界时，如何无缝升级以获取人类输入。

该示例展示这些模式如何在真实工作流中协同，以满足复杂用户请求。以下是差旅预订流程：

Human Delegates to Agent ：用户对 TravelOrchestratorAgent 说：

"帮我订下周去纽约办公室出差参加 Q3 规划会议的行程。给我订可退款机票，并预订我们公司首选合作酒店的房间。"
Agent Delegates to Agent：TravelOrchestratorAgent 分解目标并委派子任务：
- 把 "查找下周飞 JFK 的可退款航班" 发给其专家 FlightBookingAgent
- 把 "查找下周纽约公司合作酒店的房间" 发给其专家 HotelBookingAgent
Agent Calls Proxy Agent：FlightBookingAgent 必须使用公司的安全差旅门户（Concur）。它调用 ConcurProxyAgent，并传递航班筛选条件。该 proxy 是唯一持有 API keys、能够安全与 Concur 服务交互的智能体。
Agent Calls Human ：HotelBookingAgent 发现首选合作酒店已满房。它找到了另外两家已批准酒店，但无法自行决策，于是触发升级：

"公司合作酒店不可用。你更偏好 Hotel A（离办公室更近）还是 Hotel B（设施更好）？" 编排器暂停工作流。
Human Calls Agent：用户收到通知并回复："订 Hotel A。" 这是一条直接的事务型指令，用于消除歧义。

TravelOrchestratorAgent 接收人的决策后，指示 HotelBookingAgent 继续执行，收集所有专家的最终确认，并向用户呈现完整行程单（itinerary）。

与我们在第 7 章中的方法一致，本章也包含了关于模式串联（pattern chaining）与评估指标（evaluation metrics） 的专门章节。第 5、6 章探讨的基础模式聚焦于智能体协同与可观测性的内部逻辑，而第 7、8 章则聚焦于系统与真实世界相遇的关键接触点。对于人类---智能体交互而言，"成功"常常被视为主观感受。但要达到企业级系统标准，我们必须超越轶事式反馈，把用户体验转化为客观、可度量的数据。通过串联这些交互模式并应用下述指标，你可以量化 human-in-the-loop 工作流的效率，并确保智能体为其所辅助的知识工作者提供真实且可衡量的价值。

衡量成功：按模式划分的评估指标（Measuring success: evaluation metrics by pattern）

在生产级系统中，用户体验不能是意见之争；它必须可测量。实现这些模式需要精心设计与开发，因此团队必须能够量化它们带来的价值。通过为每个模式定义清晰指标，你可以跟踪其有效性、诊断薄弱点，并为持续投资以用户为中心的智能体架构提供依据。

下表给出了一些示例指标与埋点/监测（instrumentation）策略，帮助你衡量这些关键交互模式的影响。

Pattern	Metric	Instrumentation
Agent Calls Human	升级率 / 解决时长	记录每一次升级事件。测量从升级到人类响应、以及后续任务恢复执行的时间。
Human Delegates to Agent	任务成功率 / 用户满意度	跟踪被委派目标的端到端完成率。通过简单用户问卷（CSAT/NPS）进行回访。
Human Calls Agent	首次接触解决率 / 平均响应时间	测量单轮解决查询的比例。跟踪从用户输入到最终响应的端到端延迟。
Agent Delegates to Agent	编排开销 / 子任务失败率	记录每次智能体间委派与响应的时间戳，以衡量增加的延迟。跟踪专家智能体返回的错误。
Agent Calls Proxy Agent	外部 API 错误率 / 安全事件	监控 proxy agent 的日志以统计失败或超时的 API 调用；在 proxy 的隔离环境中实施安全监控。

Table 8.2 -- Sample metrics for evaluating patterns.

通过定义清晰指标，我们把抽象的"良好用户体验"目标转化为智能体系统中具体、可衡量的质量。这样的数据驱动方法对于论证这些模式所代表的架构选择、并推动持续改进至关重要。有了用于人类---智能体协作的完整模式语言，以及一套评估其影响的清晰方法论，我们已经完成了对构建"能有效与人协作"的系统的深度探讨。

让我们来详细展开 Human-Agent 交互模式。

Agent Calls Human（Human-in-the-Loop Escalation）

尽管智能体系统的目标是最大化自动化，但在某些情况下，智能体出于设计或必要性，必须暂停并向人类寻求帮助。这可能发生在：智能体对自身决策的置信度下降到某个关键阈值之下、遇到高度模糊的数据、或任务涉及高风险决策且公司政策要求必须由人类审批时。

Agent Calls Human 模式为这一关键过程提供了一套结构化机制。它定义了一条正式的升级路径（escalation path），使智能体能够优雅地暂停运行、打包必要上下文，并向人类专家请求决策，从而确保自动化与人类监督可以无缝协作。

背景（Context）

一个自治智能体在运行过程中遇到无法独立解决的情况。系统需要最大化自动化以提升效率，但也必须允许人类监督来确保安全，并处理超出智能体能力范围的边界情况（edge cases）。

问题（Problem）

智能体如何能够优雅地暂停其自治运行，并升级到人类进行干预？如果升级管理不当，可能会造成干扰、为决策提供的上下文不足，或无法正确捕获人类的反馈，从而破坏整个工作流。

解决方案（Solution）

Agent Calls Human 模式实现一个正式的升级机制，常被称为 "human-in-the-loop" 检查点。当智能体识别到需要人类介入的情形时，它会把当前状态与所有相关上下文打包成一份结构化请求。该请求随后通过专用 UI 或任务队列路由给人类操作员。智能体的工作流会暂停，直到人类给出决策；该决策再回灌到系统中，使智能体能够带着经人类验证的新信息恢复任务执行。

示例：解决贷款申请中的歧义（Example: Resolving a loan application ambiguity）

一个贷款审批系统使用智能体来处理按揭申请：

LoanApprovalAgent goal：尽可能自主处理申请，但一旦置信度低于 95% 就升级
human underwriter goal：审查智能体升级上来的模糊案例，并做出最终判断

human-in-the-loop 工作流如下展开：

触发（Trigger） ：LoanApprovalAgent 成功核验了申请人的收入与信用评分。然而在分析房产评估报告时，它检测到评估报告的建筑面积（1,800 sq. ft）与房产税记录（1,500 sq. ft）之间存在显著差异，导致其置信度下降。
打包上下文（Package context） ：智能体创建一个 "review package"，其中包含申请 ID、指向冲突文档的链接，以及一段摘要：
"在评估报告与税务记录之间发现房产面积不一致。需要人类复核以验证房产价值。"
升级（Escalate） ：它调用 HumanReviewTool，将该包推送到人类承保人（underwriter）的工作台（dashboard）。
暂停（Pause） ：该申请对应的智能体工作流被暂停，等待复核结果。
人类决策（Human decision） ：承保人审阅文档后判断税务记录属于录入错误，并通过 UI 给出决策："VALIDATE_APPRAISAL"。
恢复（Resume） ：智能体接收结构化决策，更新内部状态以反映人类覆盖（human override），并继续审批流程的下一步。

下图展示了智能体如何暂停工作流、为人类打包上下文，并在得到人类决策后恢复任务：

Figure 8.1 -- Agent Calls Human escalation flow

Figure 8.2 -- Agent Calls Human escalation flow (cont.)

示例实现（Example implementation）

下面的代码片段演示了 Agent Calls Human 模式在 Python 中的结构。注意智能体如何将自身置信度与预定义阈值进行比较，并使用专门的 HumanReviewSystem 在等待外部决策期间管理工作流的"暂停（paused）"状态。

python 复制代码

class LoanApprovalAgent:
    CONFIDENCE_THRESHOLD = 0.95
def process_application(self, application_data):
        # ... initial processing steps ...
# Analyze property appraisal
        property_analysis = self.analyze_property(application_data.appraisal)

        if property_analysis['confidence'] < self.CONFIDENCE_THRESHOLD:
            # 1. Package the context for human review
            review_package = {
                "application_id": application_data.id,
                "issue": "Property data discrepancy",
                "details": property_analysis['details']
            }

            # 2. Call the human review system and pause
            human_decision = HumanReviewSystem.request_decision(review_package)

            # 3. Act on the human's decision
if human_decision['action'] == "VALIDATE_APPRAISAL":
                self.log("Human validated appraisal. Resuming process.")
                # ... continue processing ...
return "Status: Approved"
else:
                self.log("Human rejected appraisal. Halting process.")
                return "Status: Rejected by Underwriter"
else:
            # ... continue with high-confidence automated processing ...
return "Status: Approved"
class HumanReviewSystem:
    @staticmethod
def request_decision(package):
        # In a real system, this would push to a UI and wait for a callback.
# Here, we simulate the human's response.
print(f"--> Escalation sent to Human Review Dashboard: {package['issue']}")
        return {"action": "VALIDATE_APPRAISAL"}

后果（Consequences）

优点（Pros）：

安全与信任（Safety and trust） ：该模式是构建安全、可信系统的基础。它确保关键或模糊决策会被人类审查，从而降低昂贵的自动化错误风险。
处理边界情况（Handles edge cases） ：它为应对不可避免的边界案例与新颖情境提供了健壮机制------这些往往超出智能体训练覆盖范围。

缺点（Con）：

瓶颈（Bottleneck） ：human-in-the-loop 可能成为性能瓶颈。系统整体速度会受限于人类操作员的可用性与响应速度。

实施建议（Implementation guidance）

实现该模式时，应谨慎设计面向人的界面。界面应以简洁方式呈现上下文，并提供结构化的输入方式（例如按钮与表单）让人类给出决策，以最小化歧义。确保系统具备健壮的机制来管理智能体的"暂停"状态，包括超时与默认动作：如果人类在某个期限内未响应，系统应能采取预设处理。

虽然 Agent Calls Human 模式为自动化触及能力边界时提供了关键的安全网，但大多数交互仍由用户发起。接下来，我们将探讨人类如何有效把工作卸载给智能体的模式------从复杂、长时间运行的任务开始。

Human Delegates to Agent

智能体 AI 系统的定义特征，是它们能够自主运行以达成复杂目标，超越简单的问答式交互。Human Delegates to Agent 模式抓住了这一能力的本质。人类用户不再提供逐步指令，而是把一个高层级、往往带有模糊性（ambiguous）的目标委派给智能体。该模式促成了人机关系的一次根本转变：从直接的命令---控制，转向一种伙伴关系------由人类设定战略方向（strategic direction），由智能体负责战术执行（tactical execution）。

注：模糊性的两面------委派与升级（Note: Two sides of ambiguity -- delegation versus escalation）

乍看之下，这个模式似乎与 Agent Calls Human 相矛盾。但它们并不冲突，而是互补，定义了健壮伙伴关系的两面：

Human Delegates to Agent（战略性模糊，strategic ambiguity） ：人类给智能体一个高层级、"模糊"的战略目标（例如：生成一份竞品报告）。智能体的首要工作，是通过制定一个具体的、逐步的计划来消解这种模糊性。
Agent Calls Human（战术性模糊，tactical ambiguity） ：这是安全网。当智能体在执行计划时遇到一个新的、未预见的战术问题，并且它无法或不应独自解决时（例如：竞品定价数据被密码保护，我应该跳过还是等待？），就触发升级。

简而言之：有能力的智能体 能够消解用户最初的战略模糊性；安全的智能体知道何时应升级新的战术模糊性。

这也是最接近大众想象中 AI"个人助理（personal assistant）""copilot"或"co-scientist"的模式：它可以在最少监督下完成整段任务。它尤其适用于耗时、重复，或需要穿梭多个系统与数据源的任务。

背景（Context）

人类用户有一个高层级目标或一个复杂的多步骤任务需要完成，但他们不想、或无法手动执行每一步。他们希望把整个过程卸载给一个有能力的自治系统。

问题（Problem）

用户如何能有效地把一个复杂目标交给 AI 智能体？系统必须能够从高层级指令中准确捕捉用户意图，在较长时间跨度内自主运行，并在无需持续人类指导的情况下仍与原始目标保持对齐。

解决方案（Solution）

Human Delegates to Agent 模式把交互结构化为一次清晰的"交接（handoff）"。用户提供一个高层级目标。随后智能体进入自治循环：首先生成实现该目标的详细计划，将其拆解为更小、可执行的子任务；然后执行该计划，使用工具与推理能力逐步处理每一步。智能体可能会周期性提供进度更新，或在遇到无法恢复的模糊性时请求澄清；除此之外，它会独立运行直至最终目标达成。

示例：委派市场调研（Example: Delegating market research）

一位市场经理把一项研究任务委派给 MarketAnalysisAgent：

用户委派的目标（User's delegated goal） ：经理下达指令：

"生成一份关于我们新产品 'ProWidget X' 在欧洲市场前三大竞争对手的报告。重点关注他们的定价、关键功能以及近期客户情绪。我需要明天之前拿到一个草稿。"
智能体生成的计划（Agent's generated plan） ：MarketAnalysisAgent 接收目标并将其拆解为内部计划：
1. Identify competitors：使用 web search 工具找出 'ProWidget X' 在欧洲的主要竞争对手。
2. Get pricing：对每个竞争对手，使用 financial data API 获取产品定价。
3. Analyze sentiment：对每个竞争对手，使用产品评论聚合器汇总过去 6 个月的客户情绪。
4. Synthesize report：将所有收集到的数据整合为结构化报告文档。
5. Deliver：通过 email 将最终报告发送给经理。
自治执行（Autonomous execution） ：智能体按顺序执行各子任务，使用工具，并把中间发现存入记忆，无需进一步人类输入。
完成（Completion） ：报告草拟完成后，智能体向市场经理发送邮件并附上文档，完成最初委派目标。

Figure 8.3 -- Human Delegates to Agent workflow

示例实现（Example implementation）

下面的示例代码展示了从战略目标到战术执行的转变。在该示例中，MarketAnalysisAgent 作为编排器（orchestrator），先调用 LLM 生成结构化计划；随后遍历该计划，动态调用必要工具（例如 web searching 与 sentiment analysis），以自治方式实现用户的宽泛目标。

python 复制代码

# --- Placeholder Tool Definitions ---
class WebSearchTool:
    def run(self, query):
        return ["Competitor A", "Competitor B", "Competitor C"]


class ReviewAggregatorTool:
    def run(self, competitors):
        return {"Competitor A": "Positive", "Competitor B": "Mixed"}


# --- Agent Definition ---
class MarketAnalysisAgent:
    def __init__(self):
        self.web_search_tool = WebSearchTool()
        self.review_aggregator_tool = ReviewAggregatorTool()

    def _llm_create_plan(self, goal):
        # In a real system, this would be an LLM call to generate a plan.
print("AGENT: Generating plan from high-level goal...")
        return [
            {"step": 1, "action": "identify_competitors", "query": "competitors for ProWidget X in Europe"},
            {"step": 2, "action": "analyze_sentiment"},
            {"step": 3, "action": "synthesize_report"}
        ]

    def _llm_synthesize_report(self, data):
        # Simulates using an LLM to write the final report.
print("AGENT: Synthesizing final report...")
        return (
            f"Market Research Report:\n"
f"Competitors: {data['competitors']}\n"
f"Sentiment: {data['sentiment']}"
        )

    def send_email(self, to, document):
        print(f"AGENT: Emailing report to {to}.")

    def execute_delegated_task(self, high_level_goal: str):
        # 1. Use an LLM to create a plan from the goal
        plan = self._llm_create_plan(high_level_goal)

        # 2. Execute the plan
        research_data = {}

        for step in plan:
            print(f"AGENT: Executing Step {step['step']}: {step['action']}")

            if step['action'] == 'identify_competitors':
                competitors = self.web_search_tool.run(query=step['query'])
                research_data['competitors'] = competitors

            elif step['action'] == 'analyze_sentiment':
                sentiment = self.review_aggregator_tool.run(
                    competitors=research_data.get('competitors')
                )
                research_data['sentiment'] = sentiment

            # ... other steps would be executed here ...
# 3. Final step: Synthesize and deliver
        final_report = self._llm_synthesize_report(research_data)
        self.send_email(to="manager@example.com", document=final_report)

        return "Task Complete. Report has been sent."
# --- Execute the Delegation ---

agent = MarketAnalysisAgent()
goal = "Generate a report on the top competitors for 'ProWidget X'..."
agent.execute_delegated_task(goal)

后果（Consequences）

优点（Pros）：

效率（Efficiency） ：该模式对提升用户生产力极其强大，因为它允许人类把复杂、耗时的任务卸载给自治系统。
能力（Capability） ：它使得那些对单次提示（single-prompt）交互来说过大或过复杂的问题得以被解决。

缺点（Con）：

不对齐风险（Risk of misalignment） ：主要风险在于智能体误解最初的高层目标，并耗费大量资源去执行一个与用户真实意图不一致的计划。

实施建议（Implementation guidance）

为降低不对齐风险，可以考虑实现一个 Plan Confirmation 步骤：在智能体生成初始计划之后（示例中的第 2 步），先把计划展示给用户，让用户快速做一次 "go/no-go" 批准，然后再开始自治执行。这个小检查点能确保智能体对目标的解读是正确的，同时又无需用户监督每一步。

把复杂目标委派出去是一项强大能力，但许多交互更简单也更直接。既然我们已经看到智能体如何处理高层目标，接下来我们来看看用于处理即时、事务型请求的基础模式：Human Calls Agent。

Human Calls Agent

并非所有人类---智能体交互都是长周期、复杂的委派。很多时候，用户只需要一条特定信息，或希望立即执行一个单一且定义明确的动作。对于这类事务型（transactional）且直接的查询，用户期望得到快速、准确、简洁的回应。

Human Calls Agent 模式对这种基础的请求---响应循环进行了结构化。它是构建聊天机器人与语音助手等常见应用的基础，在这些应用中，智能体的主要角色是充当通往某个工具或某条信息的直接接口。

背景（Context）

用户需要一条特定信息，或希望立即执行一个单一且定义明确的动作。交互是事务型的，用户期望快速且准确的回应，而不希望出现不必要的对话步骤。

问题（Problem）

系统如何为一条事务型查询提供直接、响应迅速且准确的答案？智能体必须快速理解用户的直接指令，使用恰当工具获取信息或执行动作，并以简洁方式返回结果。

解决方案（Solution）

Human Calls Agent 模式将交互组织为一个直接的请求---响应循环。用户查询被视为一次直接调用（invocation）。智能体的主要逻辑是：对用户意图进行分类，选择完成该意图的单一最佳工具，从查询中抽取必要参数来执行工具，然后将结果返回给用户，通常尽量减少对话性铺垫（conversational filler）。该模式是构建聊天机器人、语音助手以及其他直接交互工具的基础。

示例：查询订单状态（Example: Checking an order status）

用户与零售聊天机器人交互，想知道包裹到哪了：

用户的直接指令（User's direct command） ：用户输入："Where is my order #ABC-123?"
智能体逻辑（意图分类与工具选择）（Agent's logic (intent classification & tool selection)） ：智能体的 LLM 内核立刻识别这是一个"订单状态查询（order status query）"，并判断应调用 getOrderStatusTool。
参数抽取（Parameter extraction） ：LLM 抽取出订单 ID ABC-123 作为工具所需参数。
工具执行（Tool execution） ：智能体调用工具：getOrderStatusTool(order_id="ABC-123")。工具在内部查询公司的物流数据库并返回结构化数据：{"status": "In Transit", "location": "Denver, CO", "estimated_delivery": "2025-09-22"}。
响应生成（Response generation） ：智能体的 LLM 接收工具输出，并将其格式化为清晰、简洁、可读的自然语言回应。
返回给用户（Return to user） ：聊天机器人回复："Your order #ABC-123 is currently in transit in Denver, CO, with an estimated delivery date of September 22, 2025."

Figure 8.4 -- Human Calls Agent sequence

示例实现（Example implementation）

下面的示例实现展示了事务型系统典型的"Request-Response"循环。在该场景中，RetailBotAgent 针对速度与准确性进行了优化。它主要把 LLM 用作智能路由器（intelligent router）：识别用户意图、抽取必要参数（例如 Order ID），并调用特定的 OrderStatusTool 从后端系统中获取实时数据。

python 复制代码

# --- Placeholder Tool and LLM Definitions ---
class OrderStatusTool:
    def get_schema(self):
        return {
            "name": "getOrderStatusTool",
            "parameters": {"order_id": "string"}
        }

    def run(self, order_id):
        return {
            "status": "In Transit",
            "location": "Denver, CO",
            "estimated_delivery": "2025-09-22"
        }


# --- Agent Definition ---
class RetailBotAgent:
    def __init__(self):
        self.order_status_tool = OrderStatusTool()

        # The agent's LLM is pre-configured with the tool's schema
# self.llm = LanguageModel(tools=[self.order_status_tool.get_schema()])
def handle_user_query(self, query: str):
        # 1. LLM determines which tool to call and with what parameters
# llm_response = self.llm.generate(f"User query: {query}")
# In a real system, the LLM would populate the following based on the query.
# We simulate the LLM's decision here for clarity.

        tool_to_call = "getOrderStatusTool"
        params = {"order_id": "ABC-123"}

        if tool_to_call == "getOrderStatusTool":
            # 2. Extract parameters and execute the tool
            tool_result = self.order_status_tool.run(
                order_id=params['order_id']
            )

            # 3. Generate a final response based on the tool's output
# final_response_prompt = f"Data: {tool_result}. Formulate a helpful response."
# final_response = self.llm.generate(final_response_prompt)
# We simulate the final generation step here.
            final_text = (
                f"Your order #{params['order_id']} is currently {tool_result['status']} "
f"in {tool_result['location']}, with an estimated delivery date of "
f"September 22, 2025."
            )

            return final_text
        else:
            return "I'm sorry, I can only help with order status inquiries."
# --- Execute the Interaction ---

agent = RetailBotAgent()
user_query = "Where is my order #ABC-123?"
response = agent.handle_user_query(user_query)
print(response)

后果（Consequences）

优点（Pros）：

速度与效率（Speed and efficiency） ：该模式以速度为优化目标，非常适合构建高响应的事务型助手。
简单性（Simplicity） ：逻辑直接，是最容易实现与调试的智能体模式之一。

缺点（Con）：

范围受限（Limited scope） ：它不适合复杂的多步骤任务或长时间运行的目标；它擅长的是定义清晰、单一目的的交互。

实施建议（Implementation guidance）

高质量实现该模式的关键在于健壮的工具定义。提供给智能体的工具应当有良好的文档与清晰描述，并且其参数应当是强类型（strongly typed）的------也就是说，每个参数都要显式定义数据类型，如 string、integer 或 Boolean。正是这些元数据（metadata）让 LLM 能够准确选择正确工具，并从用户的对话式查询中抽取出所需参数。

这三个模式------Agent Calls Human、Human Delegates to Agent 与 Human Calls Agent------定义了用户与系统之间的主要接口。为了让这些体验无缝发生，我们接下来将讨论两个关键的内部模式：它们治理智能体如何在幕后协作以满足用户请求，首先从"主智能体如何把工作委派给一组专家智能体"开始。

Agent Delegates to Agent

很多时候，用户把一个复杂任务委派给单个主智能体（primary agent），但要成功完成该任务，需要一组主智能体本身并不具备的专门技能。为了满足这类请求，系统需要一种方式把用户的高层目标拆解开，并把拆解得到的子任务路由给正确的专家，同时还要为用户保持无缝体验。

Agent Delegates to Agent 模式实现了这种分层或协作结构。一个主"监督者（supervisor）"智能体充当项目经理（project manager），将用户目标分解为更小任务，并把每个任务委派给合适的专门化"执行者（worker）"智能体。这样，系统就能组合多个专家的技能，解决远比任何单一智能体独自可处理的复杂问题。

背景（Context）

一个主智能体（例如 orchestrator）从用户那里接收了一个复杂任务，该任务需要多个专门技能或知识领域才能完成。

问题（Problem）

智能体系统如何在不压垮单个"通才（generalist）"智能体、也不要求用户直接与多个专门化智能体交互的情况下，完成用户的复杂请求？

解决方案（Solution）

Agent Delegates to Agent 模式实现一种分层结构，常见形态是 supervisor（orchestrator）架构。用户只与单个主智能体交互；主智能体分析用户请求并充当"项目经理"，将总体目标拆解为更小的子任务。随后它把每个子任务委派给合适的专门化"worker"智能体，由后者用其特定工具与知识完成任务。主智能体收集各 worker 的结果并综合成最终回应呈现给用户，从而让内部协作对用户不可见。

示例：综合财务分析（Example: Comprehensive financial analysis）

一位金融分析师把任务委派给其主 ResearchAssistant 智能体：

人类委派的目标（Human's delegated goal） ：分析师提问：

"给我对 CompanyCorp 做一套完整分析。我需要他们最近一次财报电话会的总结、一份股票走势图的技术分析，以及检查最近是否有负面新闻。"
主智能体的拆解计划（Primary agent's decomposition plan） ：ResearchAssistant 智能体规划任务：
- 子任务 1：总结 Q1 earnings call transcript
- 子任务 2：分析过去 3 个月股价图的支撑/阻力位
- 子任务 3：扫描最近 7 天新闻源的负面情绪
智能体间委派（Agent-to-agent delegation） ：ResearchAssistant 将子任务委派给其专家团队：
- 把总结任务发给 EarningsCallSummarizerAgent
- 把图表分析任务发给 TechnicalChartAgent
- 把新闻扫描任务发给 NewsSentimentAgent
专家执行（Specialist execution） ：每个专家智能体使用其专用工具完成任务，并将结果返回给 orchestrator。
综合与响应（Synthesis and response） ：ResearchAssistant 收集各部分分析结果，将它们综合为一份单一、连贯的报告，并呈现给人类分析师。

Figure 8.5 -- Agent Delegates to Agent architecture

示例实现（Example implementation）

下面的示例代码展示了一个分层多智能体设置，使用 Python 的 asyncio 实现并发执行。在该实现中，ResearchAssistantAgent 充当 supervisor。它并不亲自完成技术工作，而是把一个宽泛的财务查询拆解为具体任务，并把它们委派给专家智能体。这种模块化方法使每个 worker 智能体都能维护自己的专用工具与逻辑，而 supervisor 则专注于将它们的集体输出综合成最终的连贯报告。

python 复制代码

import asyncio

# --- Placeholder Specialist Agent Definitions ---
class EarningsCallSummarizerAgent:
    async def run_async(self, company):
        return f"Earnings summary for {company} is positive."
class TechnicalChartAgent:
    async def run_async(self, company):
        return f"Chart analysis for {company} shows a bullish trend."
class NewsSentimentAgent:
    async def run_async(self, company):
        return f"News sentiment for {company} is neutral."
# --- The Orchestrator Agent ---
class ResearchAssistantAgent:
    def __init__(self):
        self.summarizer_agent = EarningsCallSummarizerAgent()
        self.chart_agent = TechnicalChartAgent()
        self.news_agent = NewsSentimentAgent()

    def _llm_synthesize(self, earnings, chart, news):
        # In a real system, an LLM would synthesize this into a polished report.
return f"Financial Workup:\n- {earnings}\n- {chart}\n- {news}"
async def generate_workup(self, company_name: str):
        print(
            f"Orchestrator: Decomposing task for {company_name} "
f"and delegating to specialists..."
        )

        # Decompose and delegate tasks to run in parallel
        earnings_summary_task = self.summarizer_agent.run_async(company=company_name)
        chart_analysis_task = self.chart_agent.run_async(company=company_name)
        news_sentiment_task = self.news_agent.run_async(company=company_name)

        # Await and collect results from all specialists
        earnings_summary, chart_analysis, news_sentiment = await asyncio.gather(
            earnings_summary_task,
            chart_analysis_task,
            news_sentiment_task
        )

        print("Orchestrator: All specialist agents have returned their results.")

        # Synthesize results into a final report
        final_report = self._llm_synthesize(
            earnings_summary,
            chart_analysis,
            news_sentiment
        )
        return final_report


# --- Execute the Delegation ---
async def main():
    orchestrator = ResearchAssistantAgent()
    report = await orchestrator.generate_workup("CompanyCorp")
    print("\n--- Final Report Presented to User ---")
    print(report)


asyncio.run(main())

后果（Consequences）

优点（Pros）：

模块化与专长（Modularity and specialization） ：该模式允许构建高能力且易维护的系统。每个智能体都可以成为其领域专家，并能独立开发、测试与更新。
能力增强（Enhanced capability） ：通过组合多个专家的技能，系统能解决远比任何单一智能体可处理的复杂问题。

缺点（Con）：

编排开销（Orchestration overhead） ：系统性能与可靠性高度依赖 orchestrator 智能体。任务拆解、委派与结果综合的逻辑设计会增加复杂度，并可能引入延迟。

实施建议（Implementation guidance）

orchestrator 的规划能力是该模式最关键的组件。对于更简单、可预测的工作流，拆解计划可以是静态、预定义的一串智能体调用序列。对于更复杂、动态的任务，orchestrator 自身可能需要使用 LLM 生成多步计划，如示例所示。

编排一组内部智能体（也称 agent mesh）可以让系统解决复杂问题。然而，许多企业工作流还需要与外部第三方系统交互。本章最后一个模式 Agent Calls Proxy Agent 提供了一个安全且模块化的蓝图，用于管理这些关键的外部通信。

Agent Calls Proxy Agent

很多时候，智能体需要与处在不同安全上下文中的外部系统交互，例如第三方合作伙伴的 API 或敏感的内部数据库。让主智能体直接持有它可能需要访问的每一个外部系统的凭证，是巨大的安全风险，也会把集成工作变成一场噩梦。系统需要一种方式来安全、可靠地管理这些交互。

Agent Calls Proxy Agent 模式通过引入一个专门的中介（intermediary）来实现这一点，这个中介被称为 "proxy"。它充当通往外部系统的安全且标准化的网关，从而把核心智能体逻辑与外部集成的复杂性解耦，并将安全策略的执行集中化。

背景（Context）

智能体在满足用户请求的过程中，需要与外部系统交互。由于安全策略、网络边界，或希望抽象掉外部系统复杂性的原因，不允许主智能体直接访问该外部系统。

问题（Problem）

智能体如何在不与外部系统紧耦合、且不牺牲安全性的前提下，安全并可靠地与外部系统交互？

解决方案（Solution）

Agent Calls Proxy Agent 模式引入一个专门的中介智能体------proxy------作为安全且标准化的网关。主智能体不直接调用外部系统；相反，它向 proxy 智能体发送一个简单的内部请求。proxy 是唯一持有与外部系统通信所需凭证与逻辑的组件。它将主智能体的请求翻译成外部系统所要求的特定格式，执行安全交互，然后再把（往往很复杂的）响应翻译回一个简单、标准化的格式，供主智能体使用。

示例：跨企业会员积分计划（Example: Cross-enterprise loyalty program）

用户正在通过 AirlineBookingAgent 订机票，并希望使用合作酒店连锁的会员计划折扣：

Primary agent (AirlineBookingAgent) ：管理用户的机票预订工作流
Proxy agent (HotelBonanzaProxyAgent) ：安全管理与外部 HotelBonanza API 的所有通信
External system：HotelBonanza 合作伙伴 API

该交互以安全且高效的方式处理：

用户请求（User request） ：用户对 AirlineBookingAgent 说：
"订去伦敦的航班，并应用我的 'HotelBonanza' 会员折扣。"
主智能体动作（Primary agent action） ：AirlineBookingAgent 知道自己不被允许直接访问 HotelBonanza 系统。
调用 proxy（Call to proxy） ：它调用 HotelBonanzaProxyAgent，发送一个简单的内部请求：
{"action": "validate_discount", "user_id": "user123", "loyalty_code": "HB-XYZ"}。
proxy 执行（Proxy execution） ：HotelBonanzaProxyAgent（唯一持有秘密 API keys 的智能体）接收请求，将其格式化为外部 HotelBonanza 系统所需的具体 API 调用，并安全发送。
外部响应（External response） ：HotelBonanza API 返回一个复杂的 JSON 对象，确认折扣有效。
proxy 翻译（Proxy translation） ：proxy 智能体解析响应，抽取关键内容（一次性折扣码），并向主智能体返回一个简单、标准化的响应：
{"status": "success", "discount_code": "APPLIED123"}。
任务完成（Task completion） ：AirlineBookingAgent 接收该简化响应并将折扣码应用到机票预订中，在整个过程中从未处理外部凭证或复杂 API 逻辑，从而完成用户请求。

Figure 8.6 -- Agent Calls Proxy Agent pattern for secure interaction

示例实现（Example implementation）

下面的实现强调了核心业务逻辑与外部系统集成之间的关注点分离。AirlineBookingAgent（主智能体）运行在高信任环境中，但缺乏跨网络访问所需的凭证；它使用简单的内部词汇进行通信。相对地，HotelBonanzaProxyAgent 位于安全、隔离的上下文中；只有它持有敏感 API keys，并具备将内部请求翻译为外部第三方所需复杂格式的特定逻辑。

python 复制代码

# --- Placeholder for external interaction ---
def http_post(url, data, headers):

    print(f"PROXY: Calling external API at {url}...")

    # Simulate a complex response from the external API
return {"external_status": "OK", "data": {"one_time_code": "APPLIED123", "valid_until": "2025-09-22"}}

# --- Resides in the main application context ---
class AirlineBookingAgent:

    def apply_partner_discount(self, user_id, loyalty_code):

        # The primary agent only knows about the internal proxy

        proxy = HotelBonanzaProxyAgent()

        proxy_request = {

            "action": "validate_discount",

            "user_id": user_id,

            "loyalty_code": loyalty_code

        }

        # The call is simple and uses internal language

        proxy_response = proxy.handle_request(proxy_request)

        return proxy_response.get('discount_code')

# --- Resides in a secure, isolated context ---
class HotelBonanzaProxyAgent:

    def __init__(self):

        # This proxy is the only component with the secret API key
# self.api_key = load_secret("HOTEL_BONANZA_API_KEY")
self.api_key = "SECRET_API_KEY"
def handle_request(self, internal_request: dict):

        # 1. Translate the internal request into the external API format

        external_request = {"user": internal_request["user_id"], "code": internal_request["loyalty_code"]}

        # 2. Securely call the external system

        external_response = http_post(

            "https://api.hotelbonanza.com/v2/discounts",

            data=external_request,

            headers={"Authorization": f"Bearer {self.api_key}"}

        )

        # 3. Translate the complex external response back to a simple internal format
if external_response.get("external_status") == "OK":

            return {"status": "success", "discount_code": external_response["data"]["one_time_code"]}

        else:

            return {"status": "failure", "discount_code": None}

# --- Execute the Workflow ---

booking_agent = AirlineBookingAgent()

discount = booking_agent.apply_partner_discount("user123", "HB-XYZ")

print(f"Booking Agent received discount code: {discount}")

后果（Consequences）

优点（Pros）：

安全（Security） ：该模式通过集中化并隔离外部系统访问显著提升安全性。主智能体永远不接触敏感凭证，从而减少攻击面（attack surface）。
解耦与可维护性（Decoupling and maintainability） ：它将主智能体系统与外部 API 的复杂性解耦。如果合作伙伴 API 发生变化，只需要更新 proxy 智能体；主智能体无需改动。

缺点（Con）：

延迟（Latency） ：它在通信链路中引入了额外的一次"跳转（hop）"，可能增加延迟，因此不太适合对超低延迟响应有强要求的交互。

实施建议（Implementation guidance）

使用该模式在内部智能体系统与外部世界之间建立清晰的安全边界。proxy 智能体应当是唯一具备访问特定外部服务所需网络权限与凭证的组件。确保主智能体与 proxy 之间的内部通信协议简单且标准化，等价于创建一个内部 API，以屏蔽外部复杂性。

这些交互模式------从高层委派到安全的 proxy 调用------为设计人类与智能体高效协作的系统提供了一整套工具箱。既然我们已经探索了各个独立的构件，最后一步就是理解如何以战略方式应用它们。

现在，让我们后退一步，在总结中整合我们已经确立的关键原则。

总结（Summary）

本章探讨了治理人类与 AI 智能体之间接口的关键模式。我们已经确立：要让智能体系统真正有用并值得信任，其与人的交互必须以意图（intention） 、清晰（clarity）与安全（safety） 为核心进行设计。这些模式提供了管理人类---智能体协作光谱的架构性解决方案------从直接命令到复杂、长时间运行的委派（delegations）。

关键要点如下：

交互形态多样（Interactions are diverse） ：人类与智能体的关系并非单一形态。它覆盖从快速、事务型调用（Human Calls Agent）到复杂、长期的交接式委派（Human Delegates to Agent）。一个健壮系统必须支持这些不同模式。
升级是核心能力，而非失败（Escalation is a core feature, not a failure） ：智能系统必须了解自身边界。Agent Calls Human 模式是确保安全、处理歧义的基础机制，使 human in the loop 成为架构的核心组成部分。
协作应当无缝（Collaboration should be seamless） ：用户不应被多智能体系统的内部复杂性所拖累。Agent Delegates to Agent 与 Agent Calls Proxy Agent 模式为构建复杂、多环节工作流提供了蓝图，同时从用户视角保持流程的简单与连贯。
建立信任是终极目标（Building trust is the ultimate goal） ：这些模式以不同方式共同服务于"建立并维持用户信任"。它们通过确保智能体理解用户意图、按目标对齐地行动、在需要时提供透明度，并代表用户安全地运行来实现这一点。

通过审慎地应用这些交互模式，我们不再只是创造"工具"，而是开始设计真正的 AI 协作者。这些模式为构建能够安全、有效嵌入人类工作流的智能体系统奠定了基础，从而释放这项变革性技术的全部潜力。

既然我们已经对如何架构人类---智能体关系有了扎实理解，就可以把焦点转向智能体自身了。在下一章中，我们将探讨agent-level patterns，它们关注单个智能体的内部设计与能力，使其能够感知环境、做出决策，并以更高的智能与自治性采取行动。