多智能体系统上下文工程-超越提示词-构建上下文与推理的透明架构引擎-四-

多智能体系统上下文工程：超越提示词，构建上下文与推理的透明架构引擎（四）

原文：Context Engineering for Multi-Agent Systems

译者：飞龙

协议：CC BY-NC-SA 4.0

final_output: Optional[str] = Any

metadata: Dict[str, Any]

```python

@app.post("/api/v1/execute")

async def execute_goal(request: GoalRequest):

    # 使用 Glass Box 引擎执行目标的主端。

    # 目前，它直接路由到 Glass Box 执行（理想情况下通过任务队列）。

    try:

        # ... (Configuration Loading Logic) ...

        # context_engine 函数需要在线程池中运行

        # 如果它保持同步状态，以避免阻塞异步事件循环 (Event Loop)。

        result, trace = await run_engine_in_threadpool(

            request.goal,

            # ... (pass clients and config) ...

        )

        return ExecutionResponse(

            status=trace.status,

            trace_id=trace.trace_id, # 假设 trace_id 已添加

            final_output=result,

            metadata={'engine_used': "GLASS_BOX", 'duration': trace.duration}

        )

    except Exception as e:

        raise HTTPException(status_code=500,

            detail=f"Engine execution failed: {str(e)}")

在企业级部署中，此 API 通过 AWS API Gateway、Kong 或 Istio 进行保护和管理。网关强制执行以下关键的交叉关注点：

• 身份验证与授权：验证 API 密钥、OAuth 令牌或 JWT，以确保只有授权的客户端可以访问引擎
• 速率限制和节流：保护引擎免受过载或拒绝服务攻击
• SSL 终止：处理 HTTPS 加密

有了这个编排层，Context Engine [在此继续...]

异步执行与任务队列

[注：为此部分提供的 OCR 文本在源码中严重损坏/乱码。根据上下文，以下代表预期的逻辑结构。]

中心化日志与可观测性

透明度是生产系统的定义特征。一旦引擎部署，其内部推理和性能在每一步都必须是可见、可测量且可验证的。这种统称为可观测性的能力，将一个仅仅能够运行的原型与一个可以被信赖的生产系统区分开来。

第 10 章

303

如 Jaeger 或 Zipkin 等追踪工具可以使这些流程端到端可见。通过在共享的 trace ID 下将每个组件的 spans 关联起来，追踪可以暴露瓶颈，并突出显示在分布式工作流中引入延迟的位置。

结构化日志、指标和追踪共同构成了 Context 引擎（Context 引擎）的完整运行视图。

基础设施与容器化

为了在大规模范围内可靠地运行，Context 引擎必须在不同环境中保持一致的行为。这种一致性通过容器化和编排来实现，它们共同定义了引擎的打包、部署和扩展方式。

例如，Docker 允许将整个应用程序（包括 Python 运行时、所需库和配置）封装到标准的镜像中。无论运行在开发者的笔记本电脑还是云集群上，每个容器的运行方式都是相同的，消除了经常困扰部署流水线的环境漂移问题。

API 层的最小化 Dockerfile 可能会如下所示：

# Dockerfile

# 使用官方 Python 运行时（slim 版本以获得更小的体积）

FROM python:3.11-slim

# 设置工作目录

WORKDIR /app

# 复制 requirements 文件

COPY requirements.txt /app/

# 安装依赖

RUN pip install --no-cache-dir -r requirements.txt

# 复制应用程序代码 (engine.py, agents.py, api.py 等)

COPY /app

# 暴露 API 端口

EXPOSE 8000

# 使用 Uvicorn 运行 API 服务器

CMD ["uvicorn", "api:app", "-host", "0.0.0.0", "-port", "8000"]

相同的镜像可以用于启动执行异步任务的 worker 进程：

# 启动 worker 的命令

celery -A tasks worker --loglevel=INFO

虽然容器提供了一致性，但 Kubernetes (K8s) 提供了协调。它是管理容器化应用的事实标准，负责处理生产环境中的部署、扩展和网络设置。

对于 Context 引擎而言，Kubernetes 管理着几个关键资源：

• Deployments（部署）：定义期望状态（例如，运行 3 个 API 镜像副本和 5 个 worker 镜像副本）。

部署企业级能力与生产护栏

• Services（服务）：提供一个稳定的网络端点以访问 API pod。
• ConfigMaps 和 Secrets：用于注入配置和密钥（与 1.1.2 节提到的中心化密钥存储集成）。
• Ingress（入口）：管理对服务的外部访问，与云提供商的负载均衡器集成。

在许多企业中，Kubernetes 集群部署在 AWS EKS、Azure AKS 或 Google GKE 等托管服务上，允许团队专注于工作负载而非基础设施。

Context 引擎必须随着负载的波动进行动态扩展。Kubernetes 通过两个内置机制处理此问题：

• Horizontal Pod Autoscaler (HPA)：Kubernetes 根据 CPU 利用率或自定义度量（如任务队列长度）自动调整 API 和 Worker Pod 的数量。如果队列增长，K8s 会启动更多的 Worker Pod 来处理增加的任务。
• Cluster Autoscaler（集群自动伸缩）：如果集群容量不足，则从云提供商处配置新节点（虚拟机）。

在第一阶段结束时，“透明箱”Context 引擎已完全部署为一个具有韧性且可观测的服务。从容器到编排逻辑，每个组件在负载下都能以可预测的方式运行。

部署企业级能力与生产护栏

随着可观测且可扩展的基础设施就绪，Context 引擎在技术上已完成部署。然而，仅有基础设施并不能定义生产系统。企业级服务的区别在于它交付的一系列可靠业务能力。引擎的真正价值在于其代理（agents）的专业技能及其信息处理流水线的强度。

第二阶段从“如何部署”转向“是什么”——什么让 Context 引擎成为关键资产。在这里，我们重新回顾早期章节中集成的能力，通过生产就绪视角对其进行重构。与其说是优化功能，不如将这些视为基础支柱，使引擎能够管理成本、确保信任、维护安全、与业务系统集成并在规模范围内执行品牌一致性。

通过主动减少上下文管理运营成本

在生产环境中，对 LLM 的每次 API 调用都会对成本和延迟产生直接且可衡的影响。一个无限制处理大型文档的引擎是一个运维负担。在第 6 章开发的用于为长文本创建简洁摘要的 Summarizer 代理，不仅是为了方便，更是一个关键的成本和性能管理工具。

在实时系统中，该代理充当智能门禁。第 6 章中用于测量 prompt 大小的count_tokens工具可以集成到 Executor 中。

• 减少 token 消耗：通过修剪上下文防止不必要的成本。
• 降低延迟：较小的 prompt 会带来更快的响应速度。
• 增加可靠性：确保系统处于 API 速率限制和预算范围内。

在第一阶段结束时，“透明箱”Context 引擎已完全部署为一个具有韧性且可观测的服务。从容器到编排逻辑，每个组件在负载下都能以可预测的方式运行。

确保信任与数据安全

防御数据管道中毒和对抗攻击

向量数据库是核心资产，像任何数据库一样，它是潜在的目标。数据中毒（向知识库插入恶意或偏见信息）是一个关键漏洞，会默默地降低质量和安全性。同样，用户输入可能被武器化。

因此，生产级 Context 引擎必须为所有数据流包含一个安全网关。helper_sanitize_input() 函数（在第 7 章引入）不是可选的工具，而是强制性的检查点。这种清洗逻辑必须应用在两个关键领域：

• 在摄取时：任何文档在未清洗之前都不应被分块和嵌入。
• 在运行时：在将任何检索到的上下文传递给 Writer 等代理之前，都会对其进行检查。

通过自动化护栏确保合规与安全

在许多行业（特别是法律、金融和医疗领域），如果没有健壮的安全和合规机制，AI 系统将无法部署。生成不当内容或误处理敏感用户输入的风险是采用技术的主要障碍。通过第 8 章实现的helper_moderate_content 函数构建的内容审核协议充当了这一至关重要的护栏。

在实时架构中，这种双阶段检查是风险管理的关键组件：

• 飞行前审核：在将用户目标发送到任务队列之前对其进行检查，防止恶意或不当请求消耗计算资源，作为第一道防线。
• 飞行后审核：在将 AI 生成的内容持久化到结果存储器之前对其进行检查，系统确保没有任何有害或不符合品牌的内容到达终端用户，从而保护用户和公司声誉。

Pinecone 向量数据库中的ContextLibrary空间不仅是提示词的集合；它还是一个集中管理、版本控制的企业身份存储库。它允许不同部门为各种任务创建并维护官方蓝图：

• 营销 (Marketing)：用于幽默且风趣的社交媒体帖子的蓝图
• 法律 (Legal)：用于正式且精确的合同条款蓝图
• 支持 (Support)：用于具有同理心且乐于助客户回复蓝图

当员工提出请求时，他们只需说明自己的高级目标。引擎会自动应用正确的、预先批准的蓝图，确保生成的每份内容（无论由谁发起）在风格上都是正确的，并符合组织标准。

在整合了第二阶段后，我们现在可以构建本章节的最后一个阶段。接下来的部分是从技术实现过渡到引人入胜的业务案例，提供必要的论点和视觉辅助，以便向项目经理、部门主管和执行利益相关者展示“玻璃箱引擎”（glass-box engine）的价值。

展示业务价值

一个生产级 AI 系统的成功部署，衡量标准不在于其架构的优雅程度，而在于它为组织创造的价值。对于项目经理和业务领导来说，Context Engine 内部代理（agents）与协议（protocols）之间复杂的相互作用必须转化为量化的收益。玻璃箱设计不仅是一个伦理选择，更是一个战略选择。它直接解决了任何企业关注的核心问题：最大化投资回报率（ROI）、建立利益相关者的信任以及创造可持续的竞争优势。

我们需要一个强大的治理层来确保整个企业的质量和一致性。这是构建引擎实物业务价值的基础。通过展示可靠性和安全性，引擎超越了工具的属性，成为一种战略资产，可以向利益相关者清晰地阐述其投资回报率。现在，我们将从引擎能力的“是什么”和“如何做”过渡到任何项目面临的终极问题：“为什么”。

这一阶段为展示已部署的 Context Engine 的业务价值提供了一个框架。我们将通过三个不同的财务和战略维度来剖析其能力：它作为价值倍增器的角色、它作为信任与合规支柱的功能，以及它为组织创造长期战略资产的潜力。

从成本中心到价值倍增器

AI 计划通常被视为成本中心，即消耗时间、资源和 API 预算但并不总能带来清晰回报的项目。Context Engine 挑战了这种认知。它被设计为一个价值倍增器，创建一个自给自足的反馈循环，效率的可以直接抵消并证明运营成本的合理。

你可以将这种动态想象为一个飞轮：每一次改进都会增加动量（如图 10.2 中的箭头所示），驱动下一次改进，直到系统从成本中心转变为真正的业务增长引擎。

图 10.2：Context Engine 的价值倍增器飞轮

飞轮模型将引擎的 ROI 可视化为持续的、强化的循环。中心是 Context Engine，它是驱动该过程的核心技术。围绕它的是三个相互关联的板块，每个板块代表一种不同形式的业务价值，由特定的代理驱动：

• 降低成本 (橙色)：该板块由 Summarizer（摘要器）代理驱动。通过在将大型文档发送到昂贵的推理模型之前主动减少其尺寸，引擎直接降低了运营支出 (OpEx)。
• 提高生产率 (绿色)：成本的节省和效率的提升释放了资源，允许 Librarian（图书管理员）代理和 Researcher（研究员）代理提高劳动力生产率。他们将研究、合成和初始草拟等枯燥、耗时的任务自动化，使员工能够专注于更高价值的战略工作。
• 加速收入 (紫色)：生产率的提高加速了业务流程。Writer（写作者）代理在品牌声线蓝图的指导下，可以快速生成高质量、符合品牌形象的营销和销售内容，缩短活动周期并加速新产品的上市时间，从而驱动收入。

飞轮创造了价值创造的广泛动态；接下来的示例展示了这些相同的能力如何转化为组织的可衡量回报：

• 直接成本节省：这是最直观的指标。Summarizer 代理不仅仅是一个功能，它是运营成本的直接杠杆。通过实施对任何超过特定阈值的文档进行自动摘要的政策，组织可以实现预测且显著的支出减少。对于处理数百份长报告的团队，即使 Token 使用量减少 40-50%，每年也能节省数千美元，足以证明了引擎的基础设施成本。
• 生产力提升和劳动力重新分配：高保真的 Researcher 代理使知识工作自动化，让员工能够专注于更高价值的战略工作。
• 加速收入：Writer 代理在品牌声线蓝图的指导下，可以快速生成高质量、符合品牌形象的营销和销售内容，缩短活动周期并加速新产品的上市时间，从而驱动收入。

第 10 章

313

1. 用户目标

（例如：分析报告）

2. 引擎流程

（规划器 -> 执行器 -> 智能体）

3. 产生的价值

（例如：带引用的摘要）

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/context-engineering-for-multi-agent-systems-move-beyond-prom/img/c9f69ac3fb58ab0dee89a12c2578a735_339_0.png

4. 捕获的资产

（记录执行轨迹日志）

图 10.4 展示了日常使用该引擎如何稳步地加强这一护城河：

• 公司 IP 与数据（黄色城堡）：中心是组织的核心知识产权，引擎的设计目的就是保护并增强这些内容。
• 知识护城河循环：这一过程始于用户目标 (1)。上下文引擎（Context Engine）利用其智能体 (2) 处理该目标，从而为用户产生价值 (3)。
• 捕获的资产：关键在于，该过程并未此结束。这项工作的副产物——执行轨迹（execution trace）会被捕获并记录为专有资产 (4)。
• 专有知识护城河（蓝色）：这些捕获的轨迹拓宽了公司 IP 周围的“知识护城河”。护城河代表了组织解决问题的独特积累智慧。这是一个成功推理链的数据集，没有任何竞争对手可以访问。

随着引擎被日复一日地，护城河不断扩大，形成了一个洞察与优势的自我增强循环。每一项新任务都增加了公司的组织知识，将使用行为本身转化为一种竞争防御的机制。

理解这一不断增长的知识库如何转化为长期战略价值，意味着从三个互补的视角来看待：

• 从公共模型到专有智能：虽然引擎使用了公开的 LLM，但它创建的输出和推理日志完全是专有的。ExecutionTrace 日志的收集代表了组织独特的思考方式。这是一个针对公司数据和业务挑战的特定应用智能数据集。
• 知识的复合效应：资产不是静态的；它会随着时间的推移而复合。在运行一年后，组织将拥有海量的成功结构化推理链数据集。这些数据可以用于强大的分析，以发现有关业务运营的洞察（例如，“我们的法律团队研究最常见的合规风险是什么？”）。
• 利用独特资产保障未来：这一专有数据集是终极的战略优势。在未来，它可以用于微调更小、更便宜或更专门的开源模型，减少对大型第三方提供者的依赖。它确保了随着 AI 格局的演变，组织拥有一项能够领先竞争对手的独特资产。

通过连接这三个价值支柱（清晰的投资回报率、信任的基础以及不断增长的知识护城河的建立），项目经理可以为持续投资“白盒化”上下文引擎提供一个极具说服力的理由。始于 AI 部署的东西最终以一个自我增强的智能引擎终终，这个引擎不断复合着组织的战略知识。

总结

本章规划了将上下文引擎从一个经过硬化的原型转变为任务关键型、企业级平台的确定性路线图。你走过了规模化部署这一透明“玻璃盒”系统所需的严谨工程路径。这段旅程深入探讨了尖端 AI 服务的实际实现，确保你已准备好在可靠性和安全性至关重要的现实场景中实施这些模式。

该过程始于在韧性的、生产就绪的基础设施中加固引擎。你学习了容器化和编排如何为扩展性提供基础，而异步任务队列和全面的可观测性栈确保了系统既有响应能力又是完全可审计的。在此基础之上，我们叠加了核心业务能力和安全护栏——从主动的成本管理和数据流水线防御，到高保真、可验证的研究和结构化数据，将引擎转变为真正的企业级就绪资产。

最后，我们将这些技术成就转化为一个极具说服力的业务案例。你学习了如何通过展示其投资回报率作为价值倍增器，向利益相关者阐述引擎的价值。始于 AI 部署的东西最终以一个自我增强的智能引擎终结，这个引擎不断复合着组织的战略知识。

第 2 步

扫描二维码或访问 packpub.com/unlock。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/context-engineering-for-multi-agent-systems-move-beyond-prom/img/c9f69ac3fb58ab0dee89a12c2578a735_344_0.png

在打开的页面上（类似于桌面端的图 11.1），按名称搜索此书书并选择正确的版本。

发现并解锁您的书籍专属福利

购买了 Packt 产品吗？您的购买可能附带免费赠品，旨在最大化您的学习效果。在此发现并解锁这些福利

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/context-engineering-for-multi-agent-systems-move-beyond-prom/img/c9f69ac3fb58ab0dee89a12c2578a735_344_1.png

图 11.1：桌面端的 Packt 解锁落地页

第 3 步

选择书籍后，登录您的 Packt 账户或免费创建一个账户。然后上传您的发票（PDF、PNG 或 JPG，大小最大 10 MB）。按照屏幕上的指令完成流程。

需要帮助

如果您遇到困难并需要帮助，请访问 https://www.packtpub.com/unlock-benefits/help 查看关于如何查找发票等的详细常见问题解答。此二维码将带您进入帮助页面。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/context-engineering-for-multi-agent-systems-move-beyond-prom/img/c9f69ac3fb58ab0dee89a12c2578a735_345_0.png

注意：如果您仍然遇到问题，请联系 customercare@packt.com。

附录 A

上下文引擎参考指南

上下文引擎（Context Engine）是一个复杂的多代理系统，旨在变换与大语言模型（LLMs）的交互范式。它超越了简单的提示-响应循环的限制，这种循环通常依赖统计概率并产生不可预测的结果。相反，上下文引擎为定向创建提供了一个结构化环境，使工程师不仅控制 AI 生成的内容，还能控制其在定义边界内的推理。这种方法将用户的角色从提问者变为架构师，设计 AI 思考过程的蓝图。

该引擎是上下文工程的实践实现，上下文工程是将生成式 AI 转换为完全控制且可靠伙伴的学科。它通过战略部署由中心规划器（Planner）和执行器（Executor）协调的代理，来实现这种控制，所有代理均通过标准化的模型上下文协议（MCP）进行通信。该系统设计为透明盒架构，优先考虑透明性、可预测安全性，适用于企业部署。

《上下文引擎参考指南》是您的技术伙伴，将书中的所有概念和代码模式整合进一个清晰、易用的格式中。它将上下文工程的理论转化为构建、扩展和维护系统的实际指令。每个章节都将前面章节解释的内容与实际实现连接起来，展示了每个函数、代理和助手如何为整体架构做出贡献。对于动手操作的读者，它提供了关于系统如何运行、数据如何流过每个组件以及如何根据现实世界需求调整设计的清晰说明。它还作为长期资源，在构建完核心上下文引擎后，支持进一步的实验、定制和协作。

理论基础

上下文引擎的核心哲学源于彻底改变我们理解语言结构和意义的语言学理论。我们不再仅仅将句子视为词的线性序列，而是将其视为意义的多维结构。这种方法深受吕西安·泰斯涅（Lucien Tesnière）和查尔斯·J·菲尔（Charles J. Fillmore）基础性工作的影响。

Tesnière 引入了依存语法，将句子可视化为分级结构（树状），其中词依赖于其他词，并围绕主动词展开。Fillmore 通过他的《格壳角色理论》（The Case Role Theory）扩展了这一点，该理论后来演变为语义角色标记（SRL）。SRL 是解构句子以回答基本问题的技术：谁对谁做了什么，在何时、何地以及为什么？（第一章）。它识别了每个组件相对于中心动作（谓语）所扮演的功能角色。

语义蓝图

上下文引擎通过使用语义蓝图（semantic blueprints）使 SRL 落地。语义蓝图是提供给 LLM 的非结构化、无歧的计划，通常为 JSON 格式。它定义了生成目标、风格指南、结构以及参与场景或主题的主员角色。

通过使用语义蓝图，我们为 LLM 提供了精确的模式而非开放式请求。这把创作行为转化为可靠的工程过程。在上下文引擎中，这些蓝图存储在专门的向量数据库（上下文库）中，并由上下文管理员（Context Librarian）代理根据用户意图动态检索。

附录 A

2. 数据摄取 (Data_Ingestion.ipynb)：此脚本处理原始文档，将其切分为可管理的分块，并关键性地为每个分块添加源元数据。这些元数据对于高保真 RAG 至关重要，能够实现可验证的引用（第 8 章）。
3. Pinecone 知识库：将处理后的分块（带有嵌入和元数据）上传到向量数据库，准备进行语义检索。

上下文引擎流 (Context Engine workflow)

这是系统的运行时操作，由context_engine()函数管理：

1. 用户目标：当用户提交一个高级目标时，工作流开始。
2. 飞行前审核检查：用户的目标会立即由helper_moderate_content函数进行审查。这是第一道安全护栏，旨在防止系统处理不适当或有害的请求。如果目标被标记，进程将停止。
3. 规划器与执行器 (Planner and Executor)：如果目标是安全的，规划器会分析目标和可用的代理能力（由AgentRegistry提供）。它生成一个多步骤执行计划。执行器接管控制，管理该计划的执行。
4. 代理工作流：执行器根据计划调用相应的代理（例如：管理员、研究员、总结器或写作者）。内部工作流随代理而异。例如，研究员的流程涉及以下步骤：
   • 检索 (Retrieve)：查询 Pinecone 知识库获取相关信息（query_pinecone）
   • 清洗 (Sanitize)：检查检索到的数据是否存在潜在的提示词注入威胁（helper_sanitize_input）
   • 合成 (Synthesizing)：使用 LLM 根据清洗后的上下文生成内容或答案（call_llm_robust）
   • 上下文链 (Context chaining)：执行器管理状态，将一个代理的输出作为下一个resolve_dependencies机制的输入。
5. 飞行后审核检查：在执行整个计划并生成最终内容后，激活第二道安全护栏。helper_moderate_content函数在将 AI 的输出返回给用户之前对其进行审查。

最终输出给用户

如果生成的内容被标记，它将自动被替换为安全消息。否则，将安全且最终确定的内容交付给用户。

这种架构确保了系统在整个运行过程中保持透明、可控和安全。规划器、执行器和代理之间的关注点分离，结合健壮的安全协议，使得上下文引擎适用于企业级部署。

commons 库引用 (The commons library reference)

commons 库包含了上下文引擎的核心实现。它被组织成若干几个 Python 模块，每个模块负责系统功能的某个特定方面。本节提供了这些模块中每个函数的详细参考。我们将开始检查提供与外部服务进行基础交互的辅助函数。

文件：helpers.py

helpers.py 文件包含重要的实用函数，处理与外部 API（如 OpenAI 和 Pinecone）的交互、数据格式化和安全协议。这些函数设计得具有健壮性，为生产环境加入了错误处理和重试逻辑。

call_llm_robust()

此集中函数处理所有与 LLM 的交互，用于内容生成和规划：

• 目的： 为调用 LLM 提供一个标准化、具韧性的接口，通过自动重试确保可靠性。

• 依赖项：

  • tenacity：用于 @retry 装饰器以处理瞬时的 API 失败
  • openai.APIError：用于特定的错误处理

• 参数：

  • system_prompt (str)：定义 AI 角色和任务约束的基础指令
  • user_prompt (str)：AI 需要处理的特定输入或数据
  • client (OpenAI client object)：用于 API 交互的初始化客户端对象（依赖注入）
  • generation_model (str)：要使用的 LLM 标识符（例如 gpt-5）
  • json_mode (bool)：如果为 True，则指示 LLM 严格以 JSON 格式返回输出

• 工作流：

  • a. 调用 client.chat.completions.create。
  • b. 根据 json_mode 设置格式。
  • c. 使用指定的模型和提示词。
  • d. 如果成功，返回内容。
  • e. 如果发生 APIError 或其他异常，记录日志并利用重试逻辑。

get_embedding()

此函数处理嵌入，用于向量表示：

• 目的： 使用指定的模型将文本转换为嵌入。

• 依赖项：

  • tenacity：用于 @retry 装饰器
  • openai.APIError：用于特定的错误处理

• 参数：

  • text (str)：要嵌入的文本
  • client (OpenAI client object)：用于 API 交互的初始化客户端对象
  • embedding_model (str)：要使用的模型标识符（例如 text-embedding-3-small）

• 工作流：

  • a. 清理输入的换行符。
  • b. 调用 client.embeddings.create。
  • c. 如果成功，返回嵌入向量。

create_mcp_message()

此函数实现了组件之间的标准化通信：

• 目的： 将数据结构化为 MCP。

• 参数：

  • sender (str)：发送者名称
  • content (dict 或 str)：主要负载
  • metadata (dict，可选)：任何元数据
  • protocol_version (str)：指定 MCP 版本

• 结构： 返回包含以下键的字典。

query_pinecone()

此函数在命名空间内与 Pinecone 交互以检索信息：

• 目的： 在命名空间内执行查询并检索信息。

• 参数：

  • query_text (str)：查询文本
  • namespace (str)：命名空间
  • top_k (int)：返回的结果数量
  • index (Pinecone index)：初始化的索引

• 工作流：

  • a. 记录尝试。
  • b. 调用 get_embedding 将 query_text 转换为向量。
  • c. 调用 index.query 并传入向量、命名空间和 top_k。
  • d. 请求包含元数据（如文本或 JSON）。
  • e. 返回匹配列表。

count_tokens()

此工具用于管理上下文长度，对于控制至关重要：

• 目的： 根据特定模型的编码方案计算文本的 token 数量。

• 依赖项： tiktoken（用于 token 计数的库）

• 参数：

  • text (str)：输入文本
  • model (str)：用于确定编码的模型标识符

• 工作流：

  • a. 尝试加载指定模型的编码。
  • b. 如果未找到模型，则回退到标准的 c100k_base 编码。
  • c. 编码并返回列表长度。

helper_sanitize_input()

此函数是一个关键的安全引入，用于缓解注入攻击的风险（第 7 章）：

• 目的： 检测并阻止与尝试操作 LLM 指令相关的模式。

• 依赖项： re（正则表达式模块）

• 参数： text (str)：要清洗的文本（通常是从向量数据库检索的数据）

• 工作流：

  • a. 函数定义了一个 injection_patterns 列表（例如：忽略之前的指令或作为）。
  • b. 遍历模式并使用 re.search（不区分大小写）检查模式是否存在于输入文本。
  • c. 如果发现模式，记录警告并抛出 ValueError，立即停止该特定文本的处理。
  • d. 如果未发现模式，记录成功消息并返回原始文本。

helper_moderate_content()

该函数实现了自动化内容审核保护层，确保引擎在负责任边界内运行（第 8 章）：

• 目的： 使用 OpenAI Moderation API 检查内容（用户输入或 AI 输出）是否违反了安全策略。

• 参数：

  • text_to_moderate (str)：需要审核的内容
  • client (OpenAI client object)：用于与 API 交互的已初始化客户端对象

• 工作流：

  • a. 该函数记录审核尝试。
  • b. 它调用 client.moderations.create 并传入输入文本。
  • c. 它解析 API 响应，以构建一个包含以下内容的详尽报告：
    • flagged (bool)：是否违反了任何策略
    • categories (dict)：违背了哪些特定类别
    • scores (dict)：每个类别的置信度评分
  • d. 如果内容被标记，它会记录一条警告。
  • e. 至关重要的一点，它包含一个“故障安全”机制：如果 API 调用由于任何原因失败（例如网络错误），它将返回一个指示内容已被标记的报告，防止未审核的内容继续。

我们现在已经在 helpers.py 文件中详细说明了基础工具。接下来，我们将检查利用这些工具执行特定任务的专家代理程序。

文件：agents.py

agents.py 文件定义了在上下文引擎（Context Engine）中执行核心任务的专家代理程序。每个代理都旨在处理特定的职责，例如检索指令、查找事实或生成内容。

agent_context_librarian()

上下文管理员（Context Librarian）负责根据输出所需的样式或结构检索相应的语义蓝图：

• 目的： 对上下文库（Context Library）进行语义搜索，以找到与用户意图匹配的蓝图。

参数：

• mcp_message (dict)：包含所需的 intent_query（意图查询）的输入消息
• client、index 和 embedding_model：传递给 query_pinecone 的依赖项
• namespace_context (str)：包含语义蓝图的 Pinecone 命名空间

工作流：

• a. 代理从 mcp_message 输入中提取 intent_query。
• b. 它调用 query_pinecone 来搜索 namespace_context（上下文库）。该命名空间中的嵌入（embeddings）对应于蓝图的描述。
• c. 如果找到匹配项，它从元数据中检索 blueprint_json 并通过 MCP 消息返回。
• d. 如果未找到匹配项，它返回一个默认的中性蓝图。

agent_researcher()

研究者（Researcher）代理负责从知识库中检索并合成事实性信息。该实现针对高保真 RAG 进行了升级，确保包含了源引用（第 8 章）：

• 目的： 寻找相关数据块，对其进行清洗，并合成一个带有引用的事实性答案。

参数：

• mcp_message (dict)：包含所需的 topic_query（主题查询）的输入消息
• client、index、generation_model 和 embedding_model：传递给 query_pinecone 和调用 call_llm_robust 的依赖项
• namespace_knowledge (str)：包含事实性数据的 Pinecone 命名空间

工作流：

• a. 代理从 mcp_message 输入中提取 topic_query。
• b. 它调用 query_pinecone 从 namespace_knowledge 中检索前三个相关数据块。
• c. 它遍历结果，对每个数据块的文本调用 helper_sanitize_input。如果某个数据块清洗失败，则跳过。
• d. 它从清洗后数据块的元数据中收集唯一的源文档名称。
• e. 它构建一个包含清洗后的素材和主题的提示词，通过 call_llm_robust 指示 LLM 根据提供的来源合成答案。
• f. 它将 LLM 的发现与程序化收集的来源相结合，并在 MCP 消息中返回 answer_with_sources（带来源的答案）。

agent_writer()

Writer 代理是最后的生成组件，负责将语义蓝图中的指令应用于事实性源素材：

• 目的： 通过结合研究结果与样式及结构指令来生成最终输出。

• 参数：

  • mcp_message (dict)：包含蓝图以及事实或 previous_content（之前的内容）的输入消息
  • client 和 generation_model：用于 call_llm_robust 的依赖项

• 工作流：

  • a. 代理从 mcp_message 输入中解包蓝图、事实和 previous_content。
  • b. 它实现了处理事实各种数据契约的逻辑（例如事实、摘要和带来源的答案），以确保与不同的上游代理（研究者或摘要器）兼容。
  • c. 它确定素材（新事实或需要重写的内容）。
  • d. 它构建一个结合语义蓝图和素材的提示词。
  • e. 它调用 call_llm_robust 根据蓝图生成最终内容。
  • f. 它在 MCP 消息中返回最终输出。

agent_summarizer()

引入摘要器（Summarizer）代理用于上下文缩减，充当门卫以管理 Token 数量和成本：

• 目的： 将长文本压缩为简要摘要，由特定的目标驱动。

参数：

• mcp_message (dict)：包含 text_to_summarize（待摘要文本）和 summary_objective（摘要目标）的输入消息

• client 和 generation_model：用于 call_llm_robust 的依赖项

• 工作流：

  • a. 代理从输入中提取 text_to_summarize 和 summary_objective。
  • b. 它构建一个提示词引导 LLM。
  • c. 它调用 call_llm_robust 进行摘要。
  • d. 它在 MCP 消息中返回摘要。

我们现在有了负责执行的代理。接下来，我们将检查组织并部署这些机制的组件。

文件：registry.py

registry.py 文件实现了代理注册表，作为代理的中央目录和工厂。它让 Planner 理解能力，并让 Executor 调用正确的代理。

类：AgentRegistry

该类管理代理函数的注册和检索：

• 初始化（__init__）
  • 构造函数初始化了 self.registry 字典，将代理名称映射到相应的函数。

方法：get_handler()

这是 Executor 使用的核心工厂方法：

• 目的： 获取对应代理名称的处理器并注入必要的依赖项。

参数：

• agent_name (str)：Planner 请求的代理名称
• client、index、generation_model、embedding_model、namespace_context 和 namespace_knowledge：运行时配置和已初始化的客户端

工作流：

• 它在 registry 中查找 agent_name。如果未找到，则抛出 ValueError。
• 它使用条件逻辑确定特定代理所需的依赖项。
• 它返回一个封装代理函数的 lambda 函数。该 lambda 接收 mcp_message 输入，并带有预注入的依赖项调用底层代理函数。这确保代理只接收它们所需的依赖项。

方法：get_capabilities_description()

这对于上下文引擎的规划阶段至关重要：

• 目的： 生成所有可用代理及其角色所需参数的结构化、可读描述。

• 工作流： 该方法返回一个多行字符串，专门用于嵌入 Planner 的系统提示词中。该描述为 Planner LLM 提供了创建有效执行计划所需的工具信息，确保使用正确的代理名称和键。

全局对象：AGENT_TOOLKIT

在模块导入时，全局初始化一个 AgentRegistry 实例。AGENT_TOOLKIT 对象在上下文引擎（engine.py）的规划和执行阶段使用。

文件：engine.py

engine.py 文件包含了上下文引擎的核心逻辑，涵盖 Tracer、Planner 和 Executor。该文件协调了从接收目标到交付最终输出的整个过程。

类：ExecutionTrace

ExecutionTrace 类通过记录整个执行流提供了关键的调试和可观测能力：

• 目的： 维护关于计划、每个步骤的输入和输出、执行状态以及持续时间的详细记录。

• 方法：

  • __init__(self, goal)：初始化追踪，记录目标并设置开始时间。
  • log_plan(self, plan)：记录由 Planner 生成的执行计划。
  • log_step(self, step_num, planned_input, mcp_output, resolved_input)：记录单个执行步骤的详细信息，关键在于同时捕获输入（带有占位符）和实际解析的输入（引用已替换为数据）。
  • finalize(self, status, final_output=None)：完成追踪收尾工作，记录状态和最终输出，并计算总持续时间。

函数：planner()

Planner 是引擎的策略核心，负责解释目标并生成结构化的执行计划：

• 目的： 使用大语言模型（LLM）利用可用的代理能力创建一个分步的计划。

• 参数：

  • goal (str)：用户提供的层级目标。
  • capabilities (str)：由 AgentRegistry.get_capabilities_description() 生成的代理描述。
  • client 和 generation_model：call_llm_robust 函数的依赖项。

• 工作流：

  • a. 它构建一个详细的系统提示词，其中包含了可用的能力以及生成 JSON 格式计划的严格指令。
  • b. 它强调了上下文链的使用（使用 $$STEP_N_OUTPUT$$ 引用来处理依赖关系）。
  • c. 它调用 call_llm_robust 并设置 json_mode=True 以生成计划。
  • d. 解析 JSON 字符串并验证其是否符合预期的 "plan": [{...}] 结构。
  • e. 如果结构有效，则返回计划（步骤列表）。否则抛出错误。

函数：resolve_dependencies()

该辅助函数对于在执行阶段实现上下文链至关重要：

• 目的： 将步骤输入参数中的占位符依赖引用（例如 $$STEP_1_OUTPUT$$）替换为之前步骤生成的实际数据。

• 参数：

  • input_params (dict)：由 Planner 定义的当前步骤的输入参数。
  • state (dict)：包含所有之前步骤输出的执行状态。

工作流

该函数使用递归深度遍历input_params字典。如果遇到匹配依赖引用格式的字符串值，它会在state中查找对应的键。如果找到该键，则用数据替换引用；否则抛出ValueError，指示计划中存在依赖错误。

函数：context_engine

这是上下文引擎（Context Engine）的主入口点和执行器：

• 目的： 管理任务的整个生命周期，包括规划、执行、状态管理和追踪。

• 参数：

  • goal (str)：用户目标。

  • client、pc（Pinecone 客户端）和index_name：初始化的客户端和配置。

  • generation_model、embedding_model、namespace_context和namespace_knowledge：运行时配置参数。

• 工作流：

  • a. 初始化：初始化ExecutionTrace并获取AgentRegistry实例。连接到 Pinecone 索引。

  • b. 阶段 1 – 计划（Plan）：

    • 从注册表中检索能力描述。

    • 调用planner()函数生成执行计划。

    • 将计划记录到追踪中。

  • c. 阶段 2 – 执行（Execute）：

    • 初始化一个空状态字典。

    • 遍历计划中的每个步骤。

    • 依赖解析：调用resolve_dependencies。

    • 代理调用：使用call_llm_robust执行代理。

    • 状态管理：将输出更新到状态。

    • 追踪：记录每个步骤的详细信息。

  • d. 错误处理：如果在执行过程中发生错误，记录错误并停止。

签名

execute_and_display(

  goal, config, client, pc, moderation_active=False)

工作流

• 飞行前审核：如果moderation_active为True，它将对目标调用helper_moderate_content。如果被标记，则停止执行步骤。

• 执行：它调用主函数context_engine，并传入目标和配置。

• 飞行后审核：如果moderation_active为True且产生了结果，它将对结果调用helper_moderate_content。如果被标记，结果将会被脱敏。

• 显示输出：它使用 Markdown 格式显示最终（可能经过脱敏）的结果。

• 显示追踪：它会显示executeTrace（状态、耗时间和详细步骤），以用于调试和分析。

控制台（Control deck）

控制台是一个交互式单元，上下文工程师在此处为特定的运行定义任务和配置。

控制台的工作流如下：

1. 定义目标：用户提供的高层目标。

2. 定义配置：一个指定操作参数（模型、索引名称和命名空间）的字典。

3. 执行：调用执行函数，可选地激活审核。

模板

成熟的架构允许为常见模式创建通用模板。

• 模板 1 – 高保真 RAG：用于需要可验证的研究和引用的任务。规划器（Planner）通常协调图书员（Librarian）、研究员（Researcher）和作者（Writer）。

• 模板 2 – 上下文压缩：用于涉及大型文档的任务。规划器通常将摘要器（Summarizer）与作者链联，以高效管理 token 数量。

• 模板 3 – 落地推理：用于验证当知识库中缺少所需信息时，引擎不会产生幻觉。

生产环境防护：审核、清理与策略

生产级 AI 系统需要健壮的防护措施来确保可靠性、可预测性和安全性。上下文引擎实施了多层防御策略，涉及输入清理和两阶段内容审核协议。然而，最终的防护在于将 AI 集成在清晰的、人为定义的组织策略中（第 8 章）。

输入清理（提示词注入防御）

输入清理层旨在降低提示词注入风险，即恶意文本隐藏在检索数据中以操纵 LLM 的指令：

• 机制：在agent_researcher()内部实现的helper_sanitize_input()函数。

• 实现细节：

  • 从知识库检索数据后、在发送给 LLM 进行合成之前，每段文本都会根据已知的注入模式（例如“忽略之前的指令”）进行审查。

  • 如果检测到威胁模式，将完全跳过受污染的块。

两阶段内容审核协议

内容审核协议通过helper_moderate_content()函数使用 OpenAI Moderation API充当自动盾牌：

• 阶段 1 – 飞行前检查（输入审查）

  • 目的：保护系统免处理不当的用户请求。

  • 工作流：在执行开始前分析用户目标。如果被标记，整个过程将停止。

• 阶段 2 – 飞行后检查（输出审查）

  • 目的：保护用户免受 AI 生成的潜在有害内容。

  • 工作流：分析 AI 最终生成的输出。如果被标记，输出将使用标准的安全信息自动脱敏。

自动化局限性与策略的角色

虽然清理和审核是强大的工具，但它们会遇到纯技术解决方案失效的“现实因素”。例如，证词中合法的脏言，或者由语境决定恰当性的复杂文档（第 8 章）。

AI 无法直观感知组织规则（例如，在法律引用中允许使用脏言，但在邮件正文中不允许）。尝试在引擎内部用日益复杂的代码来解决这个问题会导致系统变得不可维护。

策略驱动的解决方案

真正的解决方案是架构和组织上的。工程师意识到系统包含了整个生态系统，包括业务流程和人类用户。最终的防护是一个元上下文引擎控制器（meta-context engine controller）。

这是一个位于核心上下文引擎之上的高级应用。它负责以下工作：

• 输入解析：处理混乱的现实输入（例如将邮件正文与附件分离）。

• 策略执行：执行通过组织研讨会建立的确定性、人为定义的业务规则（例如根据输入源应用不同的审核规则）。

• 控制台组装：为上下文引擎组装一个清晰、安全且无歧的控制台（目标、配置以及如moderation_active等超参数）。

这种架构将确定性的业务逻辑与非确定性的 AI 推理分离，确保系统保持健壮、可维护并符合组织的意图。

运行现实：延迟与随机性

当你部署上下文引擎时，你会观察到执行目标并非瞬时完成的。这种延迟不应被误认为是错误或效率低下；相反，它是我们架构的深层思考过程的实体体现。先进的推理框架（例如在本书编写时的 Google Gemini 2.5 Pro Ultra）表现出类似的高质量、细致的结果，同时利用了大量的计算资源和循环过程。虽然上下文引擎在规模上小得多的运行，但它继承了这种方法。至关重要的是，引擎核心的 LLM 仍然是一个随机系统。

附录 B：答案

在这里你可以找到每章末尾回顾问题的答案汇总。在将它们应用于自己的项目之前，用它来加强对上下文工程原理的理解。

第 1 章

1. 本章定义的上下文工程的主要目标是向 LLM 提出更有创造性的问题吗？（是/否）

否。本章将上下文工程定义为提供一个结构化的计划来控制和引导 AI 的输出，而不仅仅是提问。

2. “2 级：线性上下文”提供了足够的信息来控制 LLM 的风格和目的吗？（是/否）

否。线性上下文提高了事实准确性，但没有引导 AI 的风格、情绪或目的，如示例所示。

3. 5 级的“语义蓝图”是构建精确可靠 AI 回复的最有效方法吗？（是/否）

是。语义蓝图被描述为上下文架构最终的形式，提供了精确且无歧的计划。

4. 语义标记（SRL）的主要功能是检查句法的正确性吗？（是/否）

否。SRL 的主要功能是识别句子中的功能角色，从而理解“谁对谁做了什么”，并揭示其语义结构。

5. 在句子“Sarah pitched the new project”中，“Sarah”被识别为受者（ARGI）吗？（是/否）

否。“Sarah”是代理（ARGO），因为她是动作的执行者。

6. 论元修饰符（ARGM-），如时间或位置，代表了角色结构标记（SRL）中动作的核心和本质组成部分吗？（是或否）

否。论元修饰符提供了额外的上下文，但被视为动作的核心，不像施者或受事者。

7. 本章的最后一个案例是否依赖于一个单一、大型且复杂的提示词来分析会议记录？（是或否）

否。该用例演示了“上下文链”（context chaining），它在多步骤工作流中使用了一系列更简单、聚焦的提示词。

8. “上下文链”技术是否被定义为将上一次 LLM 调用的输出作为下一次调用的输入？（是或否）

是。上下文链被明确定义为一个过程，其中一个输出成为下一个的输入。

9. 在用例工作流中，“分析隐含动态”（Analyze Implicit Dynamics）这一步是为了从文本中提取显式事实和决策吗？（是或否）

否。这一步专门设计用于字里行间，以寻找未说明的情感、紧张关系和社交动态。

10. 本章的会议分析工作流是否以创建一个可操作的产物（如电子邮件草稿）作为结束？（是或否）

是。该用例的最后一步是生成一个实用的、可直接应用于业务场景的输出。

第 2 章

1. 本章的主旨是一个 LLM 最适合处理复杂工作吗？（是或否）

否。核心观点是专家团队在处理这类任务时要有效得多。

2. 编排者（Orchestrator）负责实际的研究和写作吗？（是或否）

否。编排者是项目经理。它告诉研究员（Researcher）和作者（Writer）该做什么。

3. MCP 仅仅是让 LLM 写得更好的花哨方式吗？（是或否）

否。它是一组规则，以便代理能够清晰且可靠地相互对话。

4. 研究员智能体编写最终的博客文章吗？（是或否）

否。它的唯一工作是寻找并总结信息。它将该总结交给编排者。

5. 作者智能体是直接从用户的第一个请求获取任务的吗？（是或否）

否。它是在研究员完成后从编排者那里获取指令的。

6. 你必须手动运行每个智能体来获取博客文章吗？（是或否）

否。编排者自动从头到尾处理整个过程。

7. 每条 MCP 消息是否必须包含发送者是谁以及内容是什么？（是或否）

是。创建消息的函数需要发送者和内容。

8. 是否存在一个所有智能体共享的大型提示词？（是或否）

否。每个智能体都有自己专门为其特定工作设计的特殊提示词。

9. 笔记本（notebook）中的智能体通过 HTTP 在互联网上通信吗？（是或否）

否。由于它们运行在同一个地方，它们直接通信。

10. 整个系统的最终产品仅仅是研究总结吗？（是或否）

否。最终输出是作者智能体创建的博客文章。

第 3 章

1. 系统对所有内容都只使用一种 RAG 吗？（是或否）

否。它使用了两种：一种用于抓取事实，另一种用于获取如何写作的指令。

2. 上下文库仅用于存储事实（如关于太空探索的事实）吗？（是或否）

否。它存储的是风格指南和写作指令，而不是实际事实。

3. 研究员和管理员（Librarian）在同一个地方寻找信息吗？（是或否）

否。它们在同一个数据库的两个部分查找。研究员检查知识部分，管理员检查风格指南部分。

4. 作者可以选择自己的写作风格吗？（是或否）

否。它必须遵循管理员为它找到的风格指南。

5. 编排者的主要工作是实际写作吗？（是或否）

否。编排者是项目经理。它将工作分配给其他代理。

6. 为了找到风格指南，系统会搜索整个 JSON 代码吗？（是或否）

否。它搜索的是风格指南的描述，而不是整个代码块。

7. 本章的会议分析工作流是否以创建一个可操作的产物（如电子邮件草稿）作为结束？（是或否）

是。该用例的最后一步是生成一个可以直接应用于业务场景的实用的、可用的输出。

第 4 章

1. 代理注册表（Agent Registry）被描述为管理整个系统的大脑吗？（是或否）

否。引擎核心被描述为大脑。代理注册表被描述为工具箱，它为规划器提供了能力列表，并为执行器提供了实际的代理函数。

2. 重构过程中创建utils.py文件是为了处理引擎的高层编排和规划逻辑吗？（是或否）

否。创建utils.py文件是为了移动基础逻辑，特别是为了集中处理低级设置任务如install_dependencies()和initialize_clients()，而不是高层编排。

3. 原始第 4 章原型中的主日志方法使用的是 Python 内置的 logging 模块吗？（是或否）

否。文本指出原型使用了print()，这被认为对于生产系统来说是不够的，在加固期间被替换为日志模块。

4. 在重构图书管理员（Librarian）和研究员（Researcher）代理时，是否发现了一个关键缺陷，即它们返回原始字符串而不是结构化字典？（是或否）

是。文本明确提到了图书管理员（返回原始字符串）和研究员（返回原始字符串）都存在这一缺陷，已通过将输出封装在具有一致键的字典中修复。

5. 将代码从笔记本（notebook）移动到单独的 .py 文件时，registry.py文件是否因为无法找到代理函数而崩溃？（是或否）

是。文本描述了这一完全相同的问题，即一个NameError，这是因为孤立的模块不知道agents.py文件的存在，通过导入agents解决了这个问题。

6. 复杂工作流执行测试（以海明风格重写）是否确认了引擎始终遵循“图书管理员 -> 研究员 -> 作者”的固定序列？（是或否）

否。这项特定测试的设计初衷是反对相反的结果；它强迫规划器打破该序列，并动态创建一个将两个“作者”代理链联在一起的新计划。

第 6 章

1. 摘要代理（Summarizer agent）的主要目标是从外部源添加新事实吗？（是或否）

否。摘要代理的目的是减少并压缩已经提供给引擎的现有文本。

2. count_tokens工具是否执行了对 LLM 进行内容生成的最终调用？（是或否）

否。count_tokens工具是一个度量工具，用于在文本发送到 LLM 之前计算其大小。

3. 向后兼容测试的设计是为了证明新的摘要代理运行正常吗？（是或否）

否。向后兼容测试的设计是为了证明添加新代理不会破坏引擎的现有功能。

4. 规划器仅通过更新代理注册表就能自动学习使用摘要代理吗？（是或否）

是。规划器通过从代理注册表中读取能力描述来动态创建其计划，这使其能够在不更改规划器本身代码的情况下使用新代理。

5. 引入摘要代理的主要业务理由是增加最终输出的创造性吗？（是或否）

否。主要的业务理由是通过管理发送到 LLM 的上下文大小来提高效率并降低 API 成本。

6. 在新工作流中，作者代理（Writer agent）直接从摘要代理接收其事实性输入吗？（是或否）

是。通过上下文链（context chaining），摘要代理的输出作为事实性输入传递给作者代理。

7. 添加摘要代理需要对核心engine.py文件进行重大更改吗？（是或否）

否。模块化架构允许集成新代理，而无需更改engine.py中的核心规划器逻辑或执行器逻辑。

8. summary_objective输入是否用于为摘要代理提供待压缩的完整文本？（是或否）

否。summary_objective为代理提供摘要的具体目标，而text_to_summarize输入包含完整文本。

9. 主动上下文管理（proactive context management）可以被描述为本章引入的关键策略能力吗？（是或否）

是。该术语用于定义在处理之前对上下文进行测量和压缩的新能力。

第 7 章

1. 摘要目标是从外部源添加新事实吗？（是或否）

否。摘要代理的目的是减少并压缩已经提供给引擎的现有文本。

2. count_tokens工具是否执行了对 LLM 进行内容生成的最终调用？（是或否）

否。count_tokens工具是一个度量工具，用于在文本发送到 LLM 之前计算其大小。

3. 向后兼容测试的设计是为了证明新的摘要代理运行正常吗？（是或否）

否。向后兼容测试的设计是为了证明添加新代理不会破坏引擎的现有功能。

4. 规划器仅通过更新代理注册表就能自动学习使用摘要代理吗？（是或否）

是。规划器通过从代理注册表中读取能力描述来动态创建其计划，这使其能够在不更改规划器本身代码的情况下使用新代理。

5. 引入摘要代理的主要业务理由是增加最终输出的创造性吗？（是或否）

否。主要的业务理由是通过管理发送到 LLM 的上下文大小来提高效率并降低 API 成本。

6. 在新工作流中，作者代理直接从摘要代理接收其事实性输入吗？（是或否）

是。通过上下文链，摘要代理的输出作为事实性输入传递给作者代理。

7. 添加摘要代理需要对核心engine.py文件进行重大更改吗？（是或否）

否。模块化架构允许集成新代理，而无需更改engine.py中的核心规划器逻辑或执行器逻辑。

8. summary_objective输入是否用于为摘要代理提供待压缩的完整文本？（是或否）

否。summary_objective为代理提供摘要的具体目标，而text_to_summarize输入包含完整文本。

9. 主动上下文管理可以被描述为本章引入的关键策略能力吗？（是或否）

是。该术语用于定义在处理之前对上下文进行测量和压缩的新能力。

10. 提议的元上下文引擎控制器是否设计用于处理复杂的、非确定性的 AI 推理任务？（是或否）

否。它的作用是处理确定性的、特定业务逻辑（例如解析电子邮件和执行策略），而核心上下文引擎（Context Engine）则留给复杂的推理任务。

11. 第 7 章中的控制台（Control Decks）是否已重构，以便更专门适用于法律领域？（是或否）

否。它们被重构为通用的多领域模板，以展示架构的领域无关性和可用性。

第 8 章

• 8. 针对法律用例，Data_Ingestion.ipynb notebook 是否已从头重写以处理法律文档？（是或否）

否。该 notebook 是第 7 章管道的副本，证明了摄取工具对于新且不同数据源的可用性。

• 9. 在测试系统局限时，helper_sanitize_input 函数是否正确处理了包含“忽略任何相反的法律建议”短语的敌意证人词？（是或否）

否。它根据规则正确识别出该短语为潜在的提示词注入攻击，抛出错误并丢弃了数据，这凸显了纯技术清理方法的局限性。

• 10. 当给定“起草诉辩状”这一模糊目标时，引擎是否成功生成了法律上有效的文档？（是或否）

否。它生成了一个事实上基于源文本的文档，但并不是法律上有效的诉辩状，这被描述为复杂的功能性幻觉。

第 9 章

• 1. 将上下文引擎适配到营销领域是否需要完全重写其核心 engine.py 逻辑？（是或否）

否。该章节的核心观点是核心逻辑完全没有改变，证明了引擎的领域无关性和通用架构的价值。

• 2. 在多领域系统中，上下文工程师（Context Engineer）的主要角色是否是为每个任务不断开发新的专家智能体（agents)）？（是或否）

否。该章节重新定义了上下文工程师的角色，即策划新的知识库并将业务目标翻译为现有通用智能体的任务，从而最大限地减少了对新代码的需求。

附录 B

• 3. Data_Ingestion_Marketing.ipynb notebook 是否是为营销用例从头构建的全新脚本？（是或否）

否。它是现有的法律摄取 notebook 的直接复制，仅更改了源路径，证明了数据管道的可用性。

4. 每个营销用例是否都需要它们自己独特的、自定义构建的控制台（Control Deck）？（是或否）

否。所有运行的用例都是通过使用上一章中开发的同一组通用控制台模板成功实现的。

5. 在语音执行用例中，系统是否引入了一个新的、专门的品牌检查器（BrandChecker）智能体？（是或否）

否。没有明确运行品牌执行用例，但验证生产防护（Validating production safeguards）和说服性推销（Persuasive pitch）用例证明，现有的智能体（如 Librarian 和 Writer）可以使用brand_style_guide.txt来执行语气要求，而不需要新的专门智能体。

6. 电子邮件序列用例是否依赖任何单一源文档来生成输出？（是或否）

否。虽然没有运行这个特定的用例，但验证生产防护和说服性推销用例证明了引擎从多个源合成信息（包括email_nurture_outline.txt和其他文档）以构建输出的能力。

7. 多领域系统是否通过为每个业务部门创建独立的、隔离的 AI 引擎来构建？（是或否）

否。通过为其提供新的、特定领域的知识，可以动态地重新利用单一的、中心化的玻璃盒（glass-box）引擎。

8. 为了提高创作自由，是否从第 8 章中删除了审核和安全功能？（是或否）

否。飞行前和飞行后的审核检查仍然是工作流中不可或缺的一部分，正如验证生产防护章节所示的那样。

9. 玻璃盒架构（the-glass-box architecture）的主要价值主张是其能够比任何其他方法更快地生成内容吗？（是或否）

否。玻璃盒架构的主要价值在于它的可用性、适应性和领域无关性，这使其能够以极少的代码应用于新的业务领域。

10. 战略营销引擎的成功是否取决于赋予 AI 更多的自主权和更少的人为结构？（是或否）

否。它的成功取决于相反因素：通过策划的知识提供高度结构化的环境。

第 10 章

• 1. 该章节是否建议将应用程序直接部署在虚拟机上？（是或否）

否。该章节强烈主张使用 Docker 等容器以确保不同环境之间的一致性。

• 2. 是否建议使用如 Celery 等异步队列来处理长时间运行的 AI 过程？（是或否）

是。异步队列有助于防止超时。

• 3. ExecutionTrace 日志被认为是审计的核心组件吗？（是或否）

是。ExecutionTrace被描述为调试的基础元素。

• 4. 该章节是否将摘要智能体（Summarizer agent）主要作为减少开支的工具？（是或否）

否。摘要智能体被框架为一个关键的成本管理工具。

• 5. 高保真 RAG（high-fidelity RAG）能力的主要目的是提供引用输出吗？（是或否）

是。高保真 RAG 是建立信任的基础。

• 6. 该章节是否建议仅在数据摄取点进行清理？（是或否）

否。它建议采用深度防御策略，在数据摄取时以及在运行时传递给智能体之前进行清理。

• 7. 在价值倍器概念中，引擎降低成本的能力是否直接贡献于生产力？（是或否）

是。飞轮模型展示了节约如何促进生产力。

附录 B

8. 信任支柱是否建立在安全数据管道和可验证输出的核心原则之上？（是或否）

是。图表和文字清楚地显示安全基础和可验证输出是信任业务结果的重要支持。

9. 知识护城（knowledge moat）概念是否是指ExecutionTrace日志的专有数据集，它记录了组织独特的解决问题的方法（是或否）

是。知识护城被描述为随着时间记录引擎成功的推理链而产生的独特的、复合的战略资产。

10. 章节的最终结论是否认为企业 AI 的未来将依赖于单一巨大的黑盒模型？（是或否）

否。结论明确指出，未来不在于单一的庞大模型，而在于透明架构内上下文的复杂编排。

你可能喜欢的其他书籍

如果你喜欢这本书，你可能对 Packt 的其他书籍感兴趣：

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/context-engineering-for-multi-agent-systems-move-beyond-prom/img/c9f69ac3fb58ab0dee89a12c2578a735_386_0.png

构建业务就绪生成式 AI 系统

Denis Rothman

ISBN: 97818370202690

• 实现一个具有对话 AI 代理和编排器的 AI 控制器，并具备短期、长期和跨会话记忆
• 构建具有短期、长期记忆的上下文感知能力
• 使用多模态推理、图像生成和语音功能设计跨领域自动化
• 通过集成消费级记忆理解来扩展思维链（CoT）代理
• 集成你选择的尖端模型，且不干扰现有的 GenAI 系统
• 在阻止安全漏洞的同时连接实时外部数据

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/context-engineering-for-multi-agent-systems-move-beyond-prom/img/c9f69ac3fb58ab0dee89a12c2578a735_387_0.png

实践中的 AI 代理

Valentina Alto

ISBN: 9781805801351

• 构建核心代理组件，如 LLM、记忆系统、工具集成和上下文管理
• 使用代码开发生产级代理框架，如 LangChain
• 使用编排模式创建有效的多代理系统以解决问题
• 针对电子商务、客户支持等特定行业实现特定代理
• 为具有短期和长期召回能力的代理设计稳健的记忆架构
• 结合监控、护栏和人工监督实施负责任的 AI 实践
• 为生产环境优化 AI 代理的性能和成本

Packt 正在寻找像你这样的作者

如果你兴趣成为 Packt 的作者，请访问 packtpub.com 并立即提交申请。我们已经与成千上万像你这样的开发者和技术专业人员合作，帮助他们向全球技术社区分享他们的见解。你可以提交通用申请、针对我们正在招募作者的特定热门话题进行申请，或者提交你自己的想法。

分享你的想法

现在我们已经完成了《多代理系统上下文工程》，我们非常想听听你的想法！扫描下方的二维码直接进入此书的亚马逊评论页面分享你的反馈，或在你购买的网站上留下评论。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/context-engineering-for-multi-agent-systems-move-beyond-prom/img/c9f69ac3fb58ab0dee89a12c2578a735_388_0.png

https://packt.link/r/1806690047

你的评论对我们和技术社区至关重要，并将帮助我们确保交付优质内容。

索引

A

业务价值

AI 架构 67

成本中心，到倍数价值 309, 310

演进 297

演示 308

API 网关 297

利益相关者信任，可验证性 311, 312

API 服务 (FastAPI) 100, 112

以及安全 312, 312

代理注册表 146, 147

战略资产，创建

最终加固后的代码 145, 146

上下文引擎 99, 112

高级上下文（基于角色的上下文） 3, 7, 8

架构设计 100, 101

代理防御 196

架构概览 102

代理系统 67, 68

集中执行函数 158, 159

构建，工具

竞争分析 285 – 384

代理，构建 47, 48

机动室 339, 340

辅助函数，创建 50, 51

执行与运行 339

代理重构，定义 51, 52

执行器追踪器 (Executor Tracer) 102, 113, 118

agents.py 文件 330

执行器 (Executor) 101, 102, 113-

agent_context_librarian() 332

最终预生产笔记本 (notebook) 157

agent_summary() 332

函数 103, 104

agent_writer() 332

实现 119 – 121

本地导入 155

autogen 331

模块化 155

引用链接 68

模块独立性 156

自动化上下文缓解 242

说服性上下文，合成 288 – 291

来自多个来源 100 – 102

自动化 342

规划器 (Planner) 115

局限性 342

生产安全防护，280 – 282

策略-角色 342

策略驱动的上下文 342

系统，组装 121 – 240

B

向后兼容性 225

技术方面，转换 285 – 287

为上下文 104

基础上下文（线性的） 5

用户交互 159

良好的上下文（目标导向的）2, 5

生产系统

代理注册表 (Agent Registry)，重构 145, 146

集中设置 133

蓝图 74, 92

良好的上下文（目标导向的）6, 7

解构引擎过程 154, 155

加固引擎，运行 150, 151

辅助函数，加固 130, 131

上下文数据 133, 134

上下文引擎 133, 134

构建 219

研究者 (Researcher) 223

系统阶段 212

验证 212

辅助函数

AgentRegistry(registry.py) 217, 219

模块化，增强 214, 215

主动上下文 135

上下文链 188

执行循环 186

最终化 186, 189

风格合成 189

最终加固代码 139, 140

余弦相似度 78

D

上

高级上下文（基于角色的）3, 7, 8

上下文，集成 338

数据投毒 205

依赖语法

依赖注入 134

双 RAG 71

架构设计数据准备 72, 73

运行时执行分析 72 – 74

执行器追踪器 (Execution Tracer) 113, 117, 118

执行器 (Executor) 101, 102, 113- 73

嵌入模型 334

engine.py 336, 337

合规与安全，确保你的自动化护栏 306

数据流水线部署 305

治理与质量，通过创意工作流 307, 308

运营成本，通过主动降低 305

通过高保真 RAG 确保信任和信心306

企业级上下文引擎 236 – 240

架构设计错误处理 58

代理代理控制，添加 61 – 63

MCP 消息，可靠性 59

韧性 59

用于 LLM 的稳健组件 59, 60

验证循环 152

执行日志 152

F

事实 74, 92

G

Google Colab 密钥 76

get_handler 方法 147

玻璃化引擎异步执行 301

任务队列集中日志 302

可观测性环境配置 303, 304

以及密钥管理基础设施 299

容器化生产，构建 296, 300

玻璃化系统 164

架构设计漫览 165 – 168

功能 170 – 172

职责 168, 169

H

加固引擎 151, 152

复杂工作流执行 150

运行标准工作流执行 150, 151

追踪，可视化 150

helpers.py 文件 326

call_llm_robust() 329

count_tokens() create_mcp_message() 327

get_embedding() 330

I

输入清洗 341

K

知识库 (事实性) 75

知识数据 73

L

LLM API (OpenAI) 297

LangGraph

• 参考链接 68

• 设计 273

大语言模型 (LLM) 2

• 构建鲁棒性构建 59, 60

Librarian 智能体 73

延迟 240, 343

法律合规助手 236, 256

法律知识构建 256 - 259

法律用例 260

• 上下文压缩 263, 264

• 落地推理 265 - 267

• 确定，行动

• 工程化 22, 25, 26

• 进行，调查 29 - 33

• 范围，建立 27 – 29

M

MAS 框架 68

• 控制台 (control deck) 210, 211

• 高保真追踪与输出，211, 212

MAS 工作流，架构

• 协调器 (project) 43

• 函数，实现智能体 (信息) 43

• writer 智能体 (内容创作者) 43

MAS，使用 MCP 构建 47, 48

• 客户端，初始化 44, 45

• 协调器，构建 52 - 55

• 协议，感应 45

• 系统，运行 55 - 58

MCP 规范 68

模型上下文协议 Model Context Protocol (MCP) 42, 214, 321

• MAS 工作流，使用 Kubernetes (K8s) 架构 42 - 44

• 消息 44

• 消息格式 44

• 用于，构建 MAS 44

• 验证器 60, 61

多智能体系统 (MAS) 42, 71, 163

• 构建，使用 MCP 44

元上下文引擎

• 飞行后检查 246

• 飞行前检查 246

• 控制器 252

• 元控制器 176

• 管理 71

• 微上下文工程化 71

• 程序化指令 205

• 审核 242

• 提示词注入 1

• 实现 45

• 协议，定义 45

• 审核守门员 242, 243

• 消息格式 46, 77

• 构建 243 – 245

• 集成 86

• 传输层 83

• 审核护栏 245 – 248

N

受 NASA 灵感的研究助手 196 – 199

• 架构设计

• 职责 199, 200

• 可访问 199

数据接入流水线，升级

• 实现 200

高保真 RAG 流水线

• 数据接入流水线

• 数据加载与处理 202 - 204

• 逻辑，更新

• 源文档，准备 201, 202

• 验证 204, 205

• 上下文引擎能力

• helper_sanitize_input 205, 206

• 高保真 Researcher agent 207 - 209

• 高保真 RAG 260 - 262

• 高保真 RAG 流水线，NASA 研究助手

• 高保真 RAG 系统 287

O

观测性 Stack 297

OpenAI 76

运营支出 309

智能体

• get_input 205, 206

• get_handler 205, 206

• get_output 205, 206

P

策略驱动元控制器 176

Pinecone 索引

• 初始化

• 知识构建

• 协调器 52, 55

• 协调 52, 55

• 观测性 299

规划器 100 - 102

R

多领域，通用 252

控制台 254, 255

落地推理 255

高保真 API 253, 254

RAG 流水线数据接入 74, 75

上下文库 86, 87

上下文压缩 88, 89

上下文感知系统，86

构建 86

数据处理 83

数据上传 80 – 83

定义，用于上下文 77

库 83

数据用于知识 84, 85

编排层 87, 88

基础 77

环境，准备

构建辅助函数

Researcher 智能体 207 - 209

目标分析 263, 264

推理引擎 265 - 267

S

策略驱动审核 242, 243

生产系统

• 构建 219

• 研究者 (Researcher) 223

• 系统阶段 212

• 验证 212

生产防护

• 验证 212

• 竞争分析 285 – 384

• 机动室 339, 340

• 自动化 342

• 执行与运行 339

• 来源，管理 71

双 RAG

• 架构设计数据准备 72, 73

• 运行时执行分析 72 – 74

• 管理 71

参考链接

• 主动上下文 163

• 元控制器 176

• 管理 71

• 程序化指令 205

• 审核 242

• 提示词注入 1

• 协议，定义 45

• 审核守门员 242, 243

• 消息格式 46, 77

• 构建 243 – 245

• 集成 86

• 传输层 83

• 审核护栏 245 – 248

策略驱动解决方案 260 - 262

上下文 (context)

• 工程化 22, 25, 26

• 管理 71

上下文压缩

• 落地推理 265 - 267

• 目标分析 263, 264

上下文链 188

• 执行循环 186

• 最终化 186, 189

• 风格合成 189

上下文库 86, 87

上下文感知系统 86

上下文引擎 99, 112

• 高级上下文（基于角色的上下文） 3, 7, 8

• 架构设计 100, 101

• 架构概览 102

• 辅助函数，创建 50, 51

• 执行器追踪器 (Executor Tracer) 102, 113, 118

• 执行器 (Executor) 101, 102, 113-

• agent_context_librarian() 332

• agent_summary() 332

• agent_writer() 332

• 函数 103, 104

• 实现 119 – 121

• 本地导入 155

• 模块化 155

• 模块独立性 156

• 规划器 (Planner) 115

• 来自多个来源 100 – 102

• 策略驱动解决方案 260 - 262

• 系统，组装 121 – 240

上下文工程

• 微上下文工程化 71

• 上下文压缩 263, 264

• 落地推理 265 - 267

• 目标分析 263, 264

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文数据 133, 134

上下文库 83

上下文链 188

上下文引擎 133, 134

上下文管理 71

上下文感知系统 86

上下文库 86, 87

上下文压缩 88, 89

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

上下文库 86, 87

上下文感知系统 86

上下文引擎 133, 134

上下文管理 71

上下文链 188

上下文压缩 88, 89

语义角色标注（SRL）1, 10, 11

• 动态定位，绘图 12–14, 15
• 语义角色，定义 12, 17, 18

Summarizer 智能体 163

• 构建 173–175
• 上下文压缩，172
• 实现，数据接入 200
• 微上下文，184, 285, 176, 177
• 通过总结，目标 76

特殊智能体 41, 90, 105

• Context Librarian 智能体 73
• Researcher 智能体 207–209
• Writer 智能体 43

随机性 343

战略营销引擎 274

• 上载过程 87

强目标 176

• 系统提示词 47–49
• 向量数据库（Pinecone）297

T visualize_lrl() 函数 12–14

• 任务队列 297
• Tenacity 76
• 工作线程池
• 追踪器 102
• Writer 智能体 43

十要素应用 298

方法论

48, 74, 90–92, 102, 108–110, 143

定义 S1, S2

最终加固代码 144, 145