交易前台并不缺数据，真正稀缺的是把分散的数据、制度文档和操作工具快速组织成可执行判断的能力。Jefferies 构建的交易助手没有把大语言模型当作一个独立聊天窗口，而是基于 Strands Agents 编排基础模型与外部工具，并结合 Amazon Bedrock、Amazon Bedrock Knowledge Bases 和模型上下文协议（MCP），让智能体能够推理、规划并执行受控操作。
这套方案值得关注的地方，不只是“在交易场景中使用 LLM”，而是它呈现了一条更可落地的工程路径：模型负责理解意图和规划步骤，知识库提供可追溯的企业信息，工具接口执行查询或操作，权限与审计则守住生产边界。
交易助手不是更聪明的搜索框
前台交易操作通常跨越多个系统。用户提出的一个问题，可能同时涉及内部流程、历史资料、市场或交易数据，以及特定业务工具。如果只把全部上下文塞进提示词，系统很快会遇到上下文过长、数据陈旧、权限不清和结果难以核验等问题。
基于来源摘要，可以把 Jefferies 的方案理解为四个相互配合的层次：
- Strands Agents 负责智能体编排：接收用户目标，调用基础模型进行推理和规划，并决定何时使用外部工具。
- Amazon Bedrock 提供模型访问层：应用通过托管接口调用基础模型，避免自行维护模型推理基础设施。
- Bedrock Knowledge Bases 提供企业知识检索：将内部文档检索结果作为上下文交给模型，降低仅凭模型参数回答业务问题的风险。
- MCP 统一连接数据和工具：将不同系统包装成标准化能力，使智能体不必为每个数据源维护一套完全不同的集成逻辑。
关键的架构变化是把“回答问题”拆成一条受控流水线：
用户请求
-> 智能体识别意图与约束
-> 检索内部知识库
-> 选择并调用 MCP 工具
-> 汇总证据与工具结果
-> 返回答案，或提交需要人工确认的操作
这种拆分也明确了责任边界。模型可以决定“下一步应该查询什么”，但它不应该凭空生成交易状态；知识库可以提供制度依据，但不能替代实时系统；工具能够执行操作，但必须独立完成鉴权、参数校验和审计记录。
为什么这个技术组合适合前台业务
选择智能体框架的实际价值，在于把推理循环、工具调用和模型接入从业务代码中分离出来。交易助手需要处理的不是固定问答流程，而是根据问题动态选择知识库和工具。例如，用户先询问某类交易的处理规则，智能体检索内部文档后，可能还要查询相关记录，最后才能形成带依据的答复。
MCP 在这里解决的是接口碎片化问题。不同数据源仍然拥有各自的认证方式和业务语义，但可以通过统一协议向智能体暴露工具描述、输入参数和返回结果。这样做并不会自动带来安全性；真正的安全仍取决于 MCP 服务端是否执行最小权限、身份透传、输入校验、超时控制和审计。
Bedrock Knowledge Bases 则承担知识落地工作。它适合保存操作手册、政策、产品资料和其他非结构化企业内容。检索增强生成可以让答案基于检索片段，而不是只依赖模型记忆。不过，知识库内容必须有版本、有效期和访问控制。过期制度被准确检索出来，仍然会产生错误答案。
可以这样实践：把知识库检索封装成智能体工具
下面是一个可改造的最小示例。它不是 Jefferies 生产实现的复刻，而是根据摘要中的技术组合演示如何把 Bedrock Knowledge Bases 检索能力交给 Strands Agent。
运行前需要准备 Python 3.10 或更高版本、可用的 AWS 凭证、Bedrock 模型访问权限，以及一个已经完成数据同步的 Bedrock Knowledge Base。安装依赖：
python -m venv .venv
source .venv/bin/activate
pip install strands-agents boto3
export AWS_REGION=us-east-1
export BEDROCK_KB_ID=YOUR_KNOWLEDGE_BASE_ID
export BEDROCK_MODEL_ID=YOUR_BEDROCK_MODEL_ID
将下面内容保存为 trade_assistant.py。需要替换的值通过环境变量传入：
import os
from typing import Any
import boto3
from strands import Agent, tool
from strands.models import BedrockModel
REGION = os.getenv("AWS_REGION", "us-east-1")
KNOWLEDGE_BASE_ID = os.environ["BEDROCK_KB_ID"]
MODEL_ID = os.environ["BEDROCK_MODEL_ID"]
bedrock_agent_runtime = boto3.client(
"bedrock-agent-runtime",
region_name=REGION,
)
@tool
def search_internal_policy(question: str) -> dict[str, Any]:
"""Search approved internal operating policies and return cited excerpts."""
response = bedrock_agent_runtime.retrieve(
knowledgeBaseId=KNOWLEDGE_BASE_ID,
retrievalQuery={"text": question},
retrievalConfiguration={
"vectorSearchConfiguration": {"numberOfResults": 4}
},
)
results = []
for item in response.get("retrievalResults", []):
results.append(
{
"text": item.get("content", {}).get("text", ""),
"score": item.get("score"),
"source": item.get("location", {}),
}
)
return {"results": results}
model = BedrockModel(
model_id=MODEL_ID,
region_name=REGION,
)
agent = Agent(
model=model,
tools=[search_internal_policy],
system_prompt=(
"You are an internal trading operations assistant. "
"Use the policy search tool before answering policy questions. "
"Cite the returned source metadata. If evidence is missing, say so. "
"Never claim that a trade was submitted, changed, or approved."
),
)
if __name__ == "__main__":
question = input("Question: ").strip()
if not question:
raise SystemExit("A question is required")
print(agent(question))
运行：
python trade_assistant.py
这个示例有意把工具限制为只读检索。接入真实交易或订单工具时，不应简单地把 submit_order() 暴露给模型。更稳妥的做法是将写操作拆成“生成草稿”和“确认执行”两个阶段，并在服务端验证用户身份、账户范围、产品权限、数量限制及幂等键。
MCP 工具也可以采用类似的风险分级。下面是一个示意性的工具目录，不代表特定 MCP SDK 的配置格式：
# Illustrative configuration; adapt it to the MCP client in your environment.
servers:
policy-search:
transport: stdio
command: python
args: ["servers/policy_search.py"]
permissions: ["knowledge:read"]
trade-operations:
transport: http
url: "https://internal.example/mcp"
permissions: ["trade:read", "trade:draft"]
require_human_confirmation:
- "trade.submit"
- "trade.cancel"
- "trade.amend"
配置文件只是声明意图。权限判断必须发生在工具服务端，不能依赖提示词中的“禁止调用”或客户端传来的权限标签。
从原型走向前台生产系统
摘要提到该方案带来了业务影响，但没有提供具体指标，因此不能凭空推断节省了多少时间或提升了多少交易量。团队可以围绕可验证的运行指标评估价值：平均响应时间、一次解决率、被用户采纳的答案比例、引用覆盖率、工具调用失败率，以及转人工处理的比例。
生产化时还需要处理几类容易被演示环境掩盖的问题：
- 答案可追溯：返回文档名称、版本和检索片段，让用户能核验依据。
- 数据时效性：明确区分实时交易数据、延迟数据和静态知识库内容。
- 工具最小权限：查询、生成草稿和执行操作使用不同权限，写操作默认需要人工确认。
- 提示注入防护：把检索文档视为不可信输入，禁止文档内容覆盖系统策略或工具权限。
- 完整审计：记录用户身份、模型版本、提示模板版本、检索来源、工具参数和最终结果，同时对敏感字段脱敏。
- 失败可恢复：为外部工具设置超时、重试和幂等机制；模型无法确认状态时，应明确返回“未知”，而不是猜测成功。
采用建议：先做可信助手，再做自动执行
交易助手最合理的起点通常是高频、只读、证据明确的任务，例如检索内部流程、汇总相关资料、解释操作规则和生成处理草稿。这个阶段可以验证检索质量、权限模型和用户体验，同时控制错误的影响范围。
当团队能够稳定回答“模型为什么这样说、用了哪些数据、调用了什么工具、失败后如何恢复”之后，再逐步开放受约束的写操作。Strands Agents、Amazon Bedrock、Bedrock Knowledge Bases 与 MCP 提供了搭建这类系统所需的编排、模型、知识和连接层，但金融前台能否真正采用它，最终取决于证据、权限、审计和人工确认是否被设计成系统能力，而不是停留在提示词约定中。