Amazon AWS 为其市场监控 Agent 加上护栏
Amazon AWS 于 7 月 28 日发布了一套由六个 Agent 组成的市场监控架构，但其核心思路并非扩大自主性，而是限制自主性。该系统使用 LangGraph 控制执行流程，使用 Strands 在指定步骤中进行推理，并通过 Amazon Bedrock AgentCore 承载工作负载。这种分工挑战了“由一个自主 Agent 管理整项调查”的理念。
这套参考架构面向要求严苛的金融工作流。专业 Agent 会分析证券、经纪商、风险信号和外部情报，随后由另一组件汇总其发现。检查点会在每个工作流节点后保留进度，而共享状态则决定下一步运行哪一个专业 Agent。
真正的对手是单体 Agent：它将规划、推理、工具、记忆和执行整合在一个充满不确定性的循环中。Amazon AWS 则将局部的模型判断置于具有明确路径的状态机之内。最终形成的系统，与其说像一位自主分析师，不如说更像一条受监督的调查流水线。
Amazon AWS 将一项调查拆分给六个 Agent
关键变化在于架构：AWS 将工作流控制与 Agent 判断分配给不同的软件层。
公开的示例包含一个编排器、四个专业 Agent 和一个汇总器。LangGraph 通过有向图连接这些组件，将执行表示为节点和条件边。Strands 则在每个相关节点内部运行推理与工具使用循环。
编排器首先解读用户的问题，并确定调查所需的专业 Agent。它还会将每个专业 Agent 的具体任务写入共享工作流状态。随后，LangGraph 会将执行流程导向所选 Agent，再把它们的综合输出发送给汇总器。
这一结构之所以重要，是因为这些 Agent 不会自行决定整个应用应如何继续推进。证券监控 Agent 可以分析某一证券在某个交易日的活动；经纪商监控 Agent 可以审查较长周期的价格与风险趋势，而风险监控 Agent 则评估经纪商活动。
情报 Agent 会补充外部市场背景。最终汇总器将这些独立发现整合为一份回复。每个专业 Agent 都获得各自的系统提示词、工具和聚焦上下文，而不是继承一段不断膨胀的对话历史。
AWS 通过一个涉及 AAPL 价格飙升的市场监控问题展示该设计。其他示例询问哪些经纪商曾参与交易，或异常的 TSLA 交易是否与相关消息同步出现。这些情境需要多种分析视角，但并不需要每次请求都调用所有 Agent。
这种区别带来了实际收益。图可以只调用由编排器选定的专业 Agent，也可以记录当前正在运行的 Agent，以及已经存在的输出。
这份示例实现让该设计可供审查。其共享状态包括原始查询、所需 Agent、当前位置、专业分析发现以及最终汇总。该仓库还公开了部署文件、Agent 定义、工具和 Streamlit 客户端。
不过，这个仓库是一份参考实现，而非生产性能的证据。其市场记录是覆盖 2024 年 3 月三种证券的内存模拟数据。列出的经纪商名称均为虚构，项目也没有公布准确率或延迟基准。
这一限制并未抹去其架构信号。Amazon AWS 正在向企业展示，在客户接入真实数据之前，它认为多 Agent 应用应如何拆分。接下来的问题是，为什么这种拆分更偏向显式编排，而不是更广泛的自主性。
该架构拒绝单体 Agent
AWS 将不受约束的 Agent 自主性视为生产风险，尤其是在调查需要可重复步骤和可恢复状态时。
单体 Agent 通常接收一个宽泛目标，自行选择工具、解读结果、修订计划，并判断任务何时完成。这种方式可以适用于探索性任务，但当每一项决策都会改变后续执行时，治理难度就会提高。
市场监控会迅速暴露这一弱点。一项调查可能结合交易记录、价格变动、经纪商行为、订单簿数据、风险评分和公开信息。接近流程末尾的故障，不应迫使系统重复此前的每一次查询与模型调用。
随着单一上下文不断累积工具输出，指令也可能逐渐失效。Agent 可能忽略某项限制、混淆两个分析角色，或将无关材料带入后续推理。更长的历史记录也会让调试和评估都变得更困难。
新的 LangGraph 与 Strands Agent 设计收窄了这种不确定性。作为低层编排框架的 LangGraph 掌管应用路径和共享状态；作为 Agent SDK 的 Strands，则在受限节点内提供模型推理与工具使用能力。
LangGraph 将其方法描述为在控制与自主性之间取得平衡。其编排模型支持可定制的控制流、持久化记忆、流式处理和人工审核。这些特性契合需要暂停、分支，或在继续前获得批准的调查流程。
该图仍允许动态行为。编排器会根据请求选择专业 Agent，而每个 Strands Agent 都会围绕其分配的任务进行推理。不过，这种自由度存在于应用可检查和约束的路径之中。
这正是本文的核心张力。完全自主的 Agent 承诺带来更简单的应用代码，因为由模型决定计划；AWS 的设计则接受更多显式工作流代码，以换取更清晰的状态、更窄的上下文和可识别的故障边界。
两种路径都无法消除不确定性。LangGraph 节点仍可能得出薄弱结论、选择不合适的工具，或误读检索到的数据。显式路由只是让故障的位置及其后果更容易识别。
该架构也带来了工程开销。团队必须定义状态字段、节点契约、路由行为、专业提示词和合并逻辑。修改调查流程时，可能需要更新多个组件，而不是只改一个通用提示词。
Amazon AWS 实际上是在主张：当流程会带来运营或合规后果时，这些开销是合理的。这比“多 Agent 系统需要更多 Agent”的说法更强。它意味着生产级 AI 需要在模型判断周围建立软件边界。
因此，压力落在构建通用自主 Agent 的团队身上。他们必须证明，更广泛的自主性足以抵消更难的恢复、评估和控制。在受监管的工作流中，便利性本身无法决定这种比较的结果。
LangGraph 与 Strands 如何划分工作
这套组合之所以有效，是因为 LangGraph 决定推理在哪里发生，而 Strands 决定在该受限位置内部做什么。
工作流从一个带类型的共享状态开始。它存储用户查询、会话标识符、专业任务分配、所需 Agent、当前路由位置以及每个 Agent 的发现。节点返回部分更新，LangGraph 将其合并到该状态中。
条件边会在编排器和每个专业 Agent 之后检查状态。如果仍有另一个被选中的专业 Agent，执行便转向该 Agent。待列表完成后，图会路由至汇总器，然后结束。
这一机制为系统提供了可见的执行模型。运营人员可以确定哪个节点已完成、它返回了什么，以及后续走了哪条路径。这比从单个 Agent 的对话记录中还原隐式计划更为具体。
每个节点内部的 Strands Agent 会运行独立的推理与工具循环。它接收节点分配的任务，调用允许使用的工具，解读结果，并流式输出最终答案。随后，该节点会将答案写入相应的状态字段。
上下文隔离是该设计的核心。证券监控 Agent 并不需要情报分析师可用的每一条指令或工具。为每个专业 Agent 提供更窄的上下文，可以减少无关选择，并限制一个 Agent 的历史如何影响另一个 Agent。
工具设计又增加了一层边界。该示例将报告发现、模式检索和报告执行分开。Agent 先发现一个允许使用的报告，再获得允许的字段，最后提交已验证的参数。
在公开示例中，模型不会编写任意 SQL。应用代码会根据所选报告模式检查筛选字段名称，并创建参数化查询。未知字段会被拒绝，而结果数量必须处于已定义范围内。
这并不能消除提示词注入或数据投毒。它减少了一条路径，即不受信任的模型输出可能变成不受限制的数据库查询。真实部署仍需要身份控制、授权、数据分类和输出验证。
尽管该示例通过 Amazon Bedrock 配置了 Anthropic Claude 模型，但 Strands 在框架层面仍保持模型无关。其公开的 agent SDK支持工具、模型提供商、多 Agent 模式、会话管理和可观测性集成。
这种框架选择赋予 AWS 一个有趣的位置。它可以推广 Strands 推理，而不要求 LangGraph 客户放弃现有的编排层。AgentCore 同样支持多种框架，因此托管服务并不依赖这一特定组合。
这种划分可能最吸引那些已经将应用控制与概率推理解耦的团队。这些团队可以将每个 Strands 节点视为专门的分析函数。他们可以测试其输入和输出，同时将图作为独立系统进行评估。
这并非传统的微服务设计，因为这些 Agent 共享工作流状态，并具有模型驱动的行为。不过，同样的原则依然存在：更小的组件会带来更清晰的契约和故障域。代价则是协调代码和更多需要维护的接口。
对于需要记录这些契约的工程师而言，一个可搜索的工程知识库可以连接提示词、模式、评估和运营决策。当多个专业 Agent 依赖同一份共享状态定义时，这类文档就变得尤为重要。
检查点将恢复能力变成工作流特性
基于检查点的恢复是该架构最有力的生产论据，因为它将调查状态保存在任何一次单独模型调用之外。
LangGraph 可以在每个节点完成后保存检查点。检查点会记录图的当前状态，包括此前的消息、节点输出、执行元数据和工作流中的位置。应用随后可以从该保存点恢复执行。
在 AWS 示例中，AgentCoreMemorySaver 将 LangGraph 检查点连接到 AgentCore Memory。图使用该检查点保存器进行编译，而每次调用都会接收线程和参与者标识符。这些标识符将存储状态关联到特定会话和用户。
如果某个专业代理在先前代理完成后失败，工作流可以从最近的检查点重新启动。无需通过新的模型调用重建此前的每一项发现。这能减少重复工作，并避免在完整重跑期间引入不同答案。
检查点机制也支持分析师介入。工作流可以在敏感步骤后暂停，暴露中间状态以供审查，并在获得批准后恢复。这样一来，人工审查就成为明确的状态转换，而非与代理临时展开的对话。
长时间运行的调查同样受益于这一机制。一个案例可能需要等待新信息、外部批准，或等待暂时不可用的服务恢复。持久化的图状态使这种延迟得以发生，而无需让单个进程始终持续运行。
AgentCore Memory 在短期工作流检查点之外增加了第二个概念。其内存存储可以跨交互提取和检索更长期的信息。AWS 将其描述为一种保留洞察和偏好的方式，而不是让每次会话都在毫无上下文的情况下开始。
团队不应混淆这两种角色。检查点用于恢复一次特定的图执行。长期记忆则为后续交互提供经过筛选的信息。若在没有明确保留规则的情况下将二者结合，可能引发隐私、相关性和治理问题。
Amazon Bedrock AgentCore 为工作流提供托管运行时环境。应用程序使用 AgentCore SDK 封装其入口点，然后部署容器化代理。Runtime 提供会话隔离、扩缩容、身份验证基础设施和监控集成。
该服务仍保持框架无关性。根据 AgentCore documentation，Runtime 可以托管 LangGraph、Strands、CrewAI、LlamaIndex、Google ADK 及其他代理框架。它还支持 Amazon Bedrock 内部或外部的模型。
这种灵活性改变了竞争格局。AWS 并非要求开发者用一个纵向整合的技术栈替换所有框架。它将 AgentCore 定位为团队所选择的各类编排和推理工具之下的运行层。
然而，托管部署本身并不会让应用具备生产就绪能力。团队仍需负责提示词、工具权限、状态模式、评估标准、业务逻辑和数据访问。他们还必须决定哪些故障值得重试，哪些需要人工审查。
恢复机制既可以像保留良好状态一样忠实地保留错误状态。如果早期的专业代理存储了缺乏依据的结论，后续节点可能会在每次重启后继续以此为基础。检查点需要验证闸门、版本控制，以及使过时或不安全状态失效的策略。
因此，这一设计将一个可靠性问题转化为数个更易管理的工程决策。它提供了恢复和检查执行的位置，但不会决定保存下来的推理是否值得信任。
可观测性有所帮助，但无法证明合规性
该示例提升了可追溯性，但并未证明由此产生的监测决策符合受监管机构的准确性或治理要求。
AgentCore 与 Amazon CloudWatch 和 AWS X-Ray 集成以进行监控。LangGraph 可以发出 OpenTelemetry 事件，而 Strands 支持围绕代理和工具活动进行插桩。综合这些信号，可以将工作流路由与单个模型及工具操作关联起来。
AWS 文档称，AgentCore Runtime 会公开调用、会话、延迟、节流和错误指标，也可以报告 CPU 与内存消耗。结构化 span 用于识别运行时请求、会话、端点、延迟、区域和错误类别。
这些可见性能力可帮助运营人员回答实际问题。他们可以定位缓慢的专业代理、识别受到节流的模型调用，或比较不同会话间的资源使用情况。他们还可以追踪代理在生成结果前调用了哪些工具。
observability guide 增加了一项重要限定。Runtime 托管的代理会获得自动 OpenTelemetry 插桩，但团队必须配置 CloudWatch Transaction Search。某些内存日志和追踪还需要额外设置。
运营遥测不等同于决策质量。完整的追踪可以展示错误结论是如何形成的，却不会让该结论变得可接受。监测团队需要评估数据，覆盖漏报信号、误报、缺乏依据的主张和分类不一致等问题。
该示例没有公布任何此类测量结果。它没有报告精确率、召回率、误报率、恢复成功率、端到端延迟或模型成本，也没有将六代理工作流与单一整体代理进行比较。
其数据局限同样重要。该代码库使用 AAPL、MSFT 和 TSLA 在一个月内的模拟记录。这足以支撑可复现的演示，却无法近似反映碎片化的真实市场、不断演变的模式、不完整记录或机构特定的控制措施。
外部情报代理引入了另一层不确定性。公开网络信息可能包含虚假主张、被操纵的叙事，或旨在影响自动化分析的内容。生产系统需要来源策略、溯源跟踪，以及针对间接提示词注入的防御措施。
综合代理带来了进一步的集中风险。它接收专业代理的发现并生成最终回应，因此综合错误可能扭曲原本准确的工作成果。团队必须同时评估每个专业代理和整合后的报告。
内存也带来治理问题。存储状态可能包含市场数据、分析师身份、调查细节或敏感结论。保留期限、访问控制、区域要求、删除流程和审计责任都需要明确归属。
模型推理也可能在升级后发生变化。图和提示词可能保持不变，而新配置的模型会以不同方式解读证据。因此，对模型、提示词、工具、模式和路由逻辑的变更，都应伴随版本化评估。
Amazon AWS 架构使此类测试更容易，因为组件之间拥有可见的边界。团队可以针对固定状态重放单个节点，或利用存储的专业代理发现比较综合代理输出。不过，已发布的项目并未展示这套评估体系。
这正是核心的审慎观点。AWS 提供的是可信的生产环境脚手架，而非经过验证的监测产品。企业应将“生产就绪”理解为一个仍需领域控制与量化证据来实现的架构目标。
下一批 AgentCore 部署必须证明什么
下一阶段将由真实数据、可重复的评估，以及框架灵活性能否经受企业治理考验来评判。
第一个信号是采用具有代表性的金融数据进行部署。一个可信案例应连接经过身份验证的数据源，执行机构特定的授权机制，并在真实市场条件下运行。它还应记录分析师如何审查和处置警报。
如果检查点恢复能够减少重复工作、同时不保留无效发现，这样的部署将强化 AWS 的论点。它还需要证明专业代理之间的边界能够提升调查质量或运营效率。没有量化结果的私有试点声明价值有限。
第二个信号是发布对不同架构的评估。团队需要获得证据，比较在相同任务下 LangGraph 和 Strands 代理模式与单一整体代理的表现。有用的指标包括缺乏依据的主张、工具错误、路由失误、遗漏证据、恢复行为和分析师修正。
有利的比较结果将支持这样一种主张：确定性编排能够约束模型不确定性。中性的结果则意味着额外的状态和路由代码价值有限。更差的结果将削弱接受更高架构复杂度的主要理由。
第三个信号是 AgentCore、LangGraph 和 Strands 之间更深入的互操作性。框架无关的托管听起来颇具吸引力，但生产系统依赖稳定的检查点格式、遥测规范、身份传递和升级行为。
应关注随着这三个项目不断演进，集成是否仍能得到维护；也应关注客户能否在不重建治理控制的情况下更换模型或代理框架。如果可移植性能够超越演示代码，AgentCore 将成为更具说服力的运行层。
开发者在复制该示例之前，也应审视其边界。经过模式验证的查询工具提供了有用的范式，但模拟报告并不代表完整的监测数据模型。默认提示词和专业代理角色只是起点，并非合规控制措施。
企业买家应询问每个决策边界由谁负责。图可能负责路由调查，模型可能负责解释证据，AgentCore 可能负责保留状态。这些层级都不会自动为最终结论分配责任。
知识工作者也应关注，因为同一架构适用于金融以外的领域。文档审查、客户支持、合规分析和研究工作流，同样会将固定流程与不确定判断结合起来。关键问题在于，组织允许推理发生在何处，又在哪些环节要求确定性控制。
因此，对 Amazon AWS 而言，市场监测代理与其说是检测一笔可疑交易，不如说是在定义一种企业代理模式。它在模型判断周围设置明确的软件结构，再利用托管内存和遥测来维持这一结构的运行。
这一模式前景可期，因为它让故障位置可见，并使恢复具备明确意图。它的局限也同样清晰，因为公开证据止步于模拟数据和架构主张。生产环境的采用将取决于客户是否公布量化结果。
在采用这一设计之前，先选择一个重要工作流，并定义其可接受的故障行为。然后测试专业代理、检查点和追踪是否能相较于更简单的基线改善该工作流。哪些决策真正需要模型推理，哪些又应固定在代码中？
