工作坊参与指南与讲师背景
本次由 Oracle AI Developer Advocate Nacho Martinez 主讲的工作坊聚焦于 Agent Harnesses（代理容器），旨在通过一小时的高强度内容让参与者掌握构建自主 AI 应用的核心技能。工作坊采用 GitHub Codespaces 托管，参与者只需注册 GitHub ID 即可自动获取仓库访问权限并启动开发环境。现场设有 QR 码及网站 workshopwaitingroom.com（讲师幽默表示为此域名支付了高昂费用）供快速接入。若听众对演讲感到枯燥，可直接开始动手实践。讲师特别推荐其与 Andrew Ng 及 DeepLearning.AI 合作发布的免费一小时课程，该课程深入探讨如何使 AI 代理具备自适应和学习能力。助教 Richmond 将在现场协助解答关于代码环境及工作坊流程的技术问题，确保参与者能顺利进入实验状态。
反洗钱场景与自主代理的局限性
工作坊设定了一个中型银行的 反洗钱（AML） 应用场景，旨在处理大量可疑交易。例如，当账户突然存入 100万美元 并在随后三天内通过 ATM 频繁提取总计约 5万美元 的现金时，这种异常模式会被标记为可疑。传统的人工审核效率低下，因此需要 AI 代理进行初步筛选。当前行业趋势是部署数千个自主代理来解决复杂问题，但这些代理往往缺乏人类反馈回路（Human-in-the-loop）。Nacho Martinez 指出，大语言模型本身不具备内在的记忆组件，且上下文窗口有限，导致其无法在 10小时甚至100小时 的长周期内独立解决复杂问题。因此，单纯依赖前沿模型（Frontier Models）是不够的，关键在于构建能够管理记忆、上下文和工具的 Agent Harness。
"These agents are autonomous. They don't have any human in the loop until they arrive to uh to the conclusion or the answers... The context window is limited. The memory components are something that a large language model doesn't have inherently."
Agent 技术栈与数据层的核心地位
在 AI 应用的技术架构中，通常包含交互界面、推理核心（模型）、基础设施和计算资源。然而，工作坊的核心焦点在于 数据层，因为这是开发者拥有最大控制权且可定制的部分。Agent 循环（Agent Loop） 是驱动整个应用的关键组件，它负责协调内部逻辑与外部交互。在数据层中，除了基础的循环机制外，还包含 网关（Gateway）和 MCP 以连接第三方数据源。记忆层（Memory Layer） 用于解决长期存储问题，而 上下文工程（Context Engineering） 则通过自动摘要和压缩技术来缩小模型的工作窗口，防止信息过载。此外，工具与技能（Tools and Skills） 的集成允许代理执行特定任务，从而保持上下文的精简。这种分层设计使得开发者能够构建出具备长期记忆和复杂推理能力的稳健代理系统，而非仅仅依赖模型的即时响应。
"My idea is that okay we don't need to focus so much on the frontier models... let's work on the harness which is the interesting part and the things that you can actually customize."
AI应用形态演进：从聊天机器人到智能体系统
当前的AI应用场景主要呈现三种形态：聊天机器人（Chatbot）、基于检索增强生成的应用（RAG Applications，本质是向量搜索的升级版）以及由大语言模型驱动的工作流与AI智能体（LLM-driven workflows and AI agents）。在实际工程实践中，大多数工程师日常使用的系统如Cloud Code、CodeX等，实际上是后两者的结合体。这些系统被称为Agentic Systems（智能体系统），其核心特征是结合了提供自动化的LLM驱动工作流与提供自主性的AI智能体。演讲者指出，虽然工程师们每天都在使用这些系统，但在构建自己的AI应用时往往忽视了这种架构组合的重要性。他主张不应仅通过聊天机器人或RAG来消费AI，而应专注于自动化与自主性的结合，这是更优的AI应用构建方式。
AI智能体的认知架构与“Harness”的核心地位
为了理解AI智能体，演讲者将其类比为人脑的运作机制：它是由大语言模型（LLM）提供推理能力，由数据库扩展为记忆功能，通过工具实现与操作系统等外部世界的交互（类似人类肢体），并依赖输入进行感知。人类的注意力有限，无法同时处理多个复杂任务，AI智能体的上下文窗口（Context Window）也面临类似的限制。在构建过程中，我们对LLM本身的控制力有限，但可以通过Harness（智能体框架/支架）对记忆、工具使用和感知进行精细控制。演讲者强调，Harness是当今AI领域最有趣且最重要的话题之一。相同的底层前沿模型在不同配置下表现差异巨大，改变Harness结构可以直接影响智能体在特定任务中的性能优劣。一个完整的Harness包含模型、存储方案、编码与检索组件、记忆分层策略（如短期/长期记忆）、语义层以及智能体循环机制等多个关键决策点。
存储选型争议：文件与数据库的博弈案例
在Harness的具体实现中，数据存储方案的选择引发了激烈争论。一方主张“文件至上”，认为将所有非结构化数据存入文件即可；另一方则是数据库原教旨主义者（Database Maximalists），主张将所有数据存入数据库。演讲者通过一个具体案例揭示了这一困境：当多个智能体同时写入同一个文件时，如何解决一致性问题？目前的常见变通方案是Work Trees（工作树）。然而，演讲者指出这是一种倒退，因为文件在处理并发写入时存在固有的一致性问题（Consistency Problems），如读写冲突、版本混乱等。这些问题在30年前已被数据库技术完美解决。文件适合存储大量非结构化数据，而数据库则适用于需要复杂关系和一致性的场景。盲目推崇文件存储是在重新发明轮子（Reinventing the wheel），正确的做法是根据具体用例混合使用文件与数据库，利用现代数据库技术解决并发写入等经典问题。
文件与数据库的互补性及Agent记忆组件
在构建AI Agent时，存储介质的选择至关重要。例如，当多个Agent同时尝试写入文件且缺乏事务一致性（如原子性、一致性、隔离性和持久性，即ACID）时，会出现数据冲突问题。因此，文件适用于特定场景，而数据库则擅长处理其他类型的数据需求。工程师不应局限于单一存储方式，而是应根据Agent Harness的设计灵活组合。除了持久化存储，记忆组件是围绕AI Agent构建的核心机械系统，其目的是让Agent不仅能使用信息，还能在适当时机进行信息的精炼和回忆。工程师需要决定记忆层中包含哪些内容，通常分为短期记忆和长期记忆两大类。
"Files are good for some things and databases are good for other things. We don't have to go into only one of them."
短期记忆主要体现为上下文窗口（Context Window）本身。在与Clot或CodeEx等工具交互时，任何在对话结束后消失的信息都属于短期记忆。这种记忆非常有限，一旦开启新会话，一切从零开始。长期记忆则更为复杂，内部可细分为多种类别。例如，情景记忆（Episodic Memory）包含所有发生过的对话片段、工具日志以及之前会话的摘要。这些历史记录构成了Agent的经验库，使其能够基于过往交互进行推理。
长期记忆的分类与上下文窗口的性能瓶颈
为了有效管理信息，我们将长期记忆进一步划分为程序性记忆（Procedural Memory）和语义记忆（Semantic Memory）。程序性记忆涵盖了技能和工作流，即一系列按顺序执行的操作序列；而语义记忆则存储关于用户的静态信息，如用户身份、偏好设置以及常用的框架等。之所以不能将所有数据都放入短期记忆，根本原因在于上下文窗口的容量限制及其对模型性能的影响。
研究表明，随着注意力矩阵（即上下文窗口）的增大，模型的推理性能会显著下降。即使当前模型宣称支持256k或100万token的上下文窗口，实际应用中若填满这些空间，性能表现会急剧恶化。这是因为KV Cache等机制的限制导致长上下文处理效率降低。较小的上下文窗口往往能更准确地解决问题，这一规律适用于各类任务。因此，工程师必须通过技术手段压缩上下文，避免无效信息占用宝贵的计算资源。
"The bigger the attention matrix is... the worse it performs. And this happens for every model."
上下文工程策略：摘要与压缩机制
针对长上下文的性能衰减问题，主要有两种解决思路：上下文总结（Context Summarization）和压缩（Compaction）。前者要求模型生成当前对话的简短摘要，后续交互基于该摘要继续，从而重置上下文状态。后者则更为结构化，将对话片段存入数据库或文件中，并分配唯一ID。当Agent需要回顾历史时，通过ID和偏移量检索特定片段，类似于从文件中读取数据。这种方法保留了原始细节的完整性，同时避免了将所有历史文本加载到当前上下文窗口中。
这些策略属于上下文工程（Context Engineering）的核心范畴，旨在平衡信息的丰富度与处理的效率。通过动态管理上下文内容，Agent可以在保持推理准确性的同时，处理更复杂的任务序列。工程师需根据具体场景选择是生成摘要以节省空间，还是通过ID索引保留细节以备后续调用。这种精细化的管理是构建高效Agent Harness的关键环节。
Agent循环驱动与工具/技能的动态检索
Agent Loop（智能体循环）是驱动所有组件的核心引擎。它负责组装上下文，动态从技能库、工具集、历史对话及数据库中拉取必要信息。随后进行推理，并向OpenAI或其他模型发起API调用以决定下一步行动。该循环可配置为无限运行，但在实际演示中设置了最大耐心值：最多8次迭代，每次推理限时60秒。这种配置防止了资源耗尽（如API额度用完），同时保证了系统的可控性。
面对成百上千的工具和技能，直接全部加载会导致上下文窗口瞬间溢出。例如，每个技能可能占用3,000至5,000 token，100个技能将远超限制。为此，我们提出向量嵌入（Vector Embeddings）方案。首先将所有工具和技能向量化并存入向量存储库。当Agent需要特定功能时，通过向量相似度搜索检索最相关的技能或工具。问题解决后将其卸载。这种机制确保了上下文窗口中始终只保留当前任务最相关的信息，避免了无关技能的干扰。
"I'm not putting a 100 skills at the same time into the context window... So how do you fix that? Well, there are different ways... vectorize, you create vector embeddings out of the tools and out of the skills."
此外，技能蒸馏（Skill Distillation）也是一种优化手段。通过分析之前的对话和运行记录，提取有意义的模式或知识，进一步精炼Agent的能力库。工具和技能的调用往往占据超过50%的上下文窗口，因此必须高度关注其占用情况。通过向量检索和动态加载，Agent能够在有限的上下文资源下，高效地利用庞大的工具和技能生态。
技能蒸馏与动态发现机制
在构建如 Hermes Agent 这样的智能体时，核心创新在于创建专门解决特定问题的“技能”（Skills）。以开发前端为例，开发者可以创建一个包含个人偏好（如配色风格）的技能模块。通过将这些技能转化为向量嵌入（Vector Embeddings），智能体能够在后续交互中自动匹配最相关的技能。例如，当用户提及特定的配色风格时，系统能精准识别并调用对应的历史技能。
"Skill distillation is one of the techniques that you can use to improve the learning of a model over time."
这种机制实现了动态技能发现。在组装上下文的过程中，智能体会根据需求自动拉取正确的技能和工具。这不仅是提升模型能力的手段，更是持续学习（Continual Learning）的关键组成部分。通过这种方式，即使面对不断变化的需求，智能体也能保持高效和精准。
持续学习的三种记忆架构
关于如何让模型变得更好，业界存在不同观点。有人主张修改神经网络权重（参数化记忆），也有人建议优化嵌入模型以更好地检索信息。持续学习主要分为三类：参数化记忆、表示层记忆和非参数化记忆。其中，参数化记忆涉及修改权重；表示层记忆处理嵌入向量等数据表征。然而，本次讨论聚焦于非参数化记忆，即通过外部数据和上下文增强模型能力，而不直接改变模型内部结构。
"You either work on the parametric memory... representational memory... and you also have nonparametric memory."
虽然存在低秩适应（LoRA）微调等技术，但本内容强调通过控制数据层而非权重来优化模型。这种非参数化的方法允许在不冻结前沿模型的前提下，通过外部数据增强来实现持续改进。
指令层级与自主决策流程
在使用 Chat Completions API（如 OpenAI）时，存在固有的指令层级结构。系统提示词（System Prompt）权重最高，用户请求次之。这种分层设计让模型能够区分重点，避免信息过载。技能、工具等可用资源也遵循这一层级逻辑。
在反洗钱（AML）场景中，智能体作为后台服务 24/7 运行，连接数据库并自主做出决策。它不会直接阻断账户以免误伤用户，而是生成分析报告供人类审查。这种“人机协作”模式既提高了发现过程的效率，又保留了最终的人工审核权。
"It's autonomously making decisions for the company... printing them so that a human can actually inspect them later on."
通过这种架构，智能体能够模拟公司环境进行自主分析，最终由人类介入交互和确认。
Oracle Cloud 上的反洗钱自主 Agent 演示
在实时演示中，演讲者展示了部署在 Oracle Cloud Infrastructure (OCI) 上的自主 Agent（基于 Groq 模型）。该系统自动处理模拟交易数据，区分正常与可疑活动。Agent 能够自主做出决策，将标记为“可疑”的交易加入列表。为了增强透明度与可追溯性，系统提供了可视化工具来展示 Agent 的上下文窗口（Context Window），并允许用户查看数据库中已有的客户数据等历史资产。
“It's essentially making autonomous decisions and some of them it's saying hey this one is suspicious let's add it to the list”
该 Agent 通过调用工具箱（Toolbox）中的工具，在由向量存储构建的知识空间中搜索证据。它执行大量的工具调用（Tool Calls），并在实时分析所有活动后，自动生成可疑活动报告（Suspicious Activity Reports）。演示界面还以可视化方式呈现了银行内最近发生的 30 个事件，展示了 Agent 在实时环境中进行复杂分析与自动化报告生成的能力。
记忆组件架构与权重管理
针对观众关于“情景记忆（Episodic Memory）”是否会导致 Agent 混淆先前对话的提问，演讲者解释了记忆组件的管理机制。关键在于用户可以根据用例自定义内存层架构，决定不同记忆的权重。如果情景记忆对特定任务至关重要（例如需要从过往对话中提取关键信息），用户可以选择将其向量化而非仅保存为原始文本。在当前的反洗钱场景中，由于内存组件的架构有清晰的分离，因此不存在冲突。
演讲者引入了“指令层级（Instruction Hierarchy）”概念来解释不同记忆和技能的权重分配。技能（Skills）通常位于指令层级的最底层，拥有最低的优先级。这种设计允许将技能视为即插即用（Plug-and-play）的资源。团队正在实验通过预计算嵌入，将外部、内部或第三方的技能库和工具库（如 MCPs 集合）接入 Agent。通过向量搜索，Agent 可以动态调用这些预计算的技能，而无需在每次请求中硬编码所有逻辑。这种分层架构确保了 Agent 在处理复杂任务时，能够优先关注核心指令，同时灵活调用辅助技能。
Token 消耗结构与语义缓存机制
在讨论 API 请求的成本结构时，演讲者详细拆解了发送给 OpenAI 或其他前沿模型的一次完整 HTTP 请求的组成。在典型的请求中，工具输出和检索文档（Retrieved Docs）占据了约 80% 的 Token 量，即每次请求中可能有 35,000 到 100,000 个 Token 属于这一部分，而用户查询本身仅占极小部分（约几百到一千 Token）。系统提示词和开发者指令也占据一定比例。
“80% of the whole request is tools and skills... if 80% of it was the same as the previous request it doesn't recompute it just goes into the semantic cache”
尽管这部分数据量巨大，但用户并未因此支付五倍的费用。这是因为 OpenAI 等系统引入了语义缓存（Semantic Cache）机制。当请求中的工具和技能部分与之前的请求在语义上相似时，系统不会重新计算这些 Token 的嵌入或处理结果，而是直接调用缓存。这一机制极大地降低了使用前沿模型的经济成本。如果没有语义缓存，由于每次请求都需处理大量的工具描述和技能定义，Token 消耗成本将显著增加。
Context Window 的效率与最小化策略
关于如何管理包含大量技能盒和工具模式的预算，演讲者将上下文窗口（Context Window）视为一个从非零值开始的 N 维矩阵。他引用了一篇比较不同 Harness（智能体框架）效率的论文，指出初始系统提示词和首次完成 API 请求中的 Token 数量直接影响了整体效率。例如，Pi Harness 被认为是最极简且高效的框架之一，因为它在每次请求开始时仅包含约 6,000 个 Token。相比之下，其他一些 Harness 可能在初始请求中加载多达 30,000 到 40,000 个 Token。
这种差异凸显了最小化初始上下文负载的重要性。通过保持系统提示词的精简，Agent 可以更高效地利用有限的上下文窗口来处理核心任务逻辑和实时数据。演讲者强调，清晰的架构分离不仅有助于避免记忆混淆，还能通过优化初始 Token 消耗来降低整体运营成本。选择高效的 Harness 并严格控制首次请求的上下文大小，是平衡功能丰富性与经济性的关键策略。
Agent 循环与上下文组装机制
在构建反洗钱智能体时，核心在于理解 Agent Loop（智能体循环） 如何控制其连接的所有组件。当新请求进入时，模型首先决定执行任务所需的行动，随后尝试组装上下文。默认情况下会检索三个最相关的工具或技能，这一过程通过向量搜索完成。虽然当前演示未使用重排序器（Reranker），但架构上允许在相似度搜索后加入嵌入模型加重排序器的组合，从三个候选中筛选出最关键的一个。这种策略允许根据任务复杂度动态调整加载的技能数量，例如某些简单任务可能仅需一个技能即可解决。关键在于保持策略的一致性：无论采用何种检索与筛选组合，都应在整个系统中保持一致。
"The agent loop will control everything that it connects to... determining what is the thing to do then it's going as try to assemble the context with the things that it needs to perform."
记忆层设计的简化与分层策略
在与智能体交互时，效率主要取决于创建的实体数量。建议保持记忆层设计的简洁性，避免过度抽象或创建过多组件。最基础且有效的架构仅包含 短期记忆（Short-term Memory） 和 长期记忆（Long-term Memory） 两个结构。当智能体判断短期上下文中的某些信息值得保留时，可将其提升为长期记忆并以原始文本形式存储。随后，这些文本可以被向量化并纳入智能体循环的探索范围。在观察（Observing）与推理（Reasoning）之间增加一个额外的抽象层，让智能体在解决问题前进行自省。通过计算查询向量与长期记忆中向量的距离，若相似度足够高（距离小），则将其纳入上下文窗口；否则直接丢弃。
"My first recommendation would be just like keep it simple... try to experiment first of all with only short-term memory and long-term memory and just have two structures."
MCP 在数据库交互中的价值与挑战
尽管在此特定场景中未使用模型上下文协议（MCP），但在涉及数据库交互时，MCP 的核心价值在于防止 AI 智能体产生幻觉并动态生成错误的 SQL 查询。SQL 存在多种引擎（如 PostgreSQL、Oracle Database、VSQL 等），每种都有特定的提示符或细微差别，导致动态生成的查询往往无法正常工作。MCP 通过预创建经过验证的 SQL 查询供智能体访问，解决了这一主要痛点，而非让智能体每次尝试重新发明轮子。这种预定义机制确保了查询的可靠性，避免了因引擎差异导致的执行失败。
"One of the main problems that I like to say... what does an MCP solve, especially in the database? ... letting AI agents make SQL queries, but by not hallucinating or trying to come up with a new SQL query every time."
技能存储：文本匹配与向量嵌入的对比
将技能（Skills）以纯文本形式存储在文件系统中，虽然便于人类阅读和正则表达式匹配，但 随着文件大小增加，基于关键字或单词的搜索效率会显著下降。正则表达式匹配在文件线性增长时，其性能可能呈二次方级恶化，扩展性较差。相比之下，预先计算技能的嵌入向量（Embeddings）能捕捉人类难以理解的隐藏语义。这些嵌入通常具有 384 到数千维的维度，能够保留令牌之间的复杂关系。向量搜索不仅效率更高，还能通过语义相似度更准确地召回相关技能，从而克服传统文本匹配在大规模数据下的性能瓶颈。
"If you precompute the embeddings of a skill, you're actually also capturing the meaning in these embeddings... it has a premputation of 384 minimum to 4,000 plus dimensions."
混合检索机制：语义与关键词的协同增效
在构建可发现的AI系统时，单纯依赖一种搜索方式往往存在局限。为了解决这一问题，混合检索（Hybrid Search） 成为了一种更优的解决方案。这种技术结合了 语义搜索（基于嵌入向量）和 关键词搜索 的优势，通常采用 RRF（Reciprocal Rank Fusion，倒数排名融合）算法来实现。通过这种方式，系统能够同时利用两种检索机制的能力，从而显著提升检索质量。
为了直观理解这一概念，演讲者展示了一个可视化图表。该图表描绘了语义搜索和关键词搜索结果的重合区域。中间空白部分代表了混合检索独有的高相关性结果，这些内容在单独使用语义搜索或关键词搜索时容易被遗漏。因此，虽然混合检索需要消耗更多的计算资源（compute），但随着时间推移，其检索质量的提升是显而易见的。这种策略的核心在于利用两种不同搜索类型的互补优势。从AI Agent的视角来看，增加少量计算成本以换取更高的检索精度是极具价值的投入。
自定义Harness的构建哲学：简化而非重构
对于大多数从业者而言，无需从头开发像 CodeEx 或 Cloud Code 那样复杂的底层框架。市场已有成熟的解决方案，重点应在于针对特定问题构建自定义的Harness（工具链/框架）。演讲者指出，不要试图创建一个通用的、极其复杂的系统来运行所有工作，而应简化待解决的问题，并构建能够附加在该问题之上的轻量级Harness。
以金融顾问为例，一个针对金融Agent的自定义Harness可以包含该领域所需的所有特定功能。然而，当面对不同数据类型或约束条件的问题时（如解决Navier-Stokes方程等数学难题），需求则截然不同。这类问题需要“无限耐心”或近乎无限的上下文处理能力，因为Agent在解决过程中没有人类介入（human in the loop）。因此，必须默认集成 自动上下文摘要 和 无限压缩机制。演讲者强调：从基础开始构建，可以剔除90%不必要的功能，使系统更加精简高效。
架构核心：以Chat Completions API为中心的插件化思维
在构建自定义Harness时，所有功能都应围绕 Chat Completions API 展开。尽管Anthropic和OpenAI等公司试图建立自己的标准以抵御外部竞争，但底层通信依然依赖于该API。将模型交互视为Harness的一个额外插件，这种视角能极大地简化架构设计。演讲者建议：系统越小、越精简，最终的表现往往越好。
为了帮助听众实践这一理念，演讲者提供了具体的实验环境。他设置了代码空间（Code Space），并承诺由自己支付费用，让参会者可以在家中继续使用该工作坊环境进行探索。这一举措旨在降低实践门槛，鼓励听众在不施加压力的情况下深入理解Agent Harness的概念。演讲者还提到，如果大家对Agent概念有进一步疑问，可以在Oracle展位继续交流。这种开放的支持态度旨在促进知识从理论到实践的转化。
结论
反洗钱自主代理的核心价值在于通过Agent Harness架构突破大语言模型上下文窗口限制，实现长周期复杂任务处理。其优势在于结合向量检索、混合搜索及语义缓存机制，有效管理记忆与工具调用，显著降低Token成本并提升检索精度。然而，该方案依赖非参数化记忆与外部数据层控制，无法改变模型底层权重。适用条件为需人机协作的后台分析场景，而非完全无人干预的高精度推理任务。当前架构在解决并发一致性与动态技能发现方面表现稳健，但需警惕过度依赖单一存储介质或忽视初始上下文负载优化带来的性能衰减风险。