在 Amazon Bedrock 上自建 Web Search / Web Fetch 与 Dynamic Filtering 实现笔记

背景

大模型联网搜索后做精确数值计算容易翻车。我测试过让模型搜两只股票市盈率做对比，搜到了正确网页，"推理"出来的数字却跟真实数据差了 30%。

根本原因：大模型做精确计数、排序、数值提取这类任务，天生不靠谱。它会数错、估错、跳过数据项。

Dynamic Filtering 解决这个问题的思路很直接——搜索/抓取拿到结果后，模型自己写 Python 代码对数据做处理。不靠推理"估"，靠代码"算"。

但这些工具是 Server-Managed Tools，通过亚马逊云科技的 Amazon Bedrock 暂时不能直接调用。方案是自建 Proxy 中间层。

架构核心

Proxy 做三件事：

1. 工具替换

把 Bedrock 不认识的 type: "web_search_20250305" 替换为标准 tool definition（带 name、description、input_schema）。Claude 本身理解这些工具语义，标准定义就够。

2. Agentic Loop

Proxy 自己跑多轮推理循环。调 Bedrock 模型 → 模型返回 tool_use → 调搜索/抓取服务 → 结果注入上下文 → 继续推理 → 直到 end_turn 或超过 25 次迭代。

3. 代码沙箱

增强版工具额外注入 bash_code_execution 定义。模型生成的代码在 Docker 沙箱执行（网络隔离、权限限制、内存上限 256MB）。

搜索提供商支持 Tavily（推荐）和 Brave。抓取用 httpx（零依赖）或 Tavily Extract。引用通过 system prompt 注入 + 正则后处理还原。

验证数据

Proxy vs 官方 API

测试"对比 AAPL 和 GOOGL 的市盈率"：Token 差异 < 4%，搜索查询完全一致，P/E 计算结果完全一致（AAPL 33.42, GOOGL 28.10），响应格式 100% 兼容。

三方案对比（任务：抓取页面找频率前 3 的词）

• Dynamic Filtering：6,731 tokens，100% 准确
• 纯推理：6,745 tokens，全部错误
• 本地 Agent + CodeInterpreter：24,669 tokens（3.7 倍），100% 准确

Dynamic Filtering 在相同准确率下 Token 消耗远低于 Agent + MCP 方案。原因：Proxy 只注入 2 个极简 tool definition（~185 tokens），MCP 暴露 5 个完整工具（~2,500 tokens/轮）。

跨模型：Qwen3-Coder、Kimi K2.5、MiniMax M2.1、GLM-4.7、DeepSeek 3.2 均测试通过。

部署

ENABLE_WEB_SEARCH=true \
WEB_SEARCH_PROVIDER=tavily \
WEB_SEARCH_API_KEY=tvly-your-api-key \
./scripts/deploy.sh -e prod -r us-west-2 -p arm64 -l ec2

注意：ECS 必须用 EC2 launch type，Fargate 没有 Docker daemon。标准版不需要 Docker 环境。

客户端只改 base_url 一行：

client = anthropic.Anthropic(
    base_url="https://your-proxy-endpoint.com",
    api_key="your-proxy-api-key",
)

局限

• 搜索结果质量依赖 Tavily/Brave，跟官方自有引擎有差异
• 引用系统基于提示工程，极少数情况标记丢失
• 增强版需要 Docker，增加部署复杂度
• 跨模型引用遵从率参差不齐，Claude 较高

详见原文：基于 Amazon Bedrock 实现 Dynamic Filtering Web Search 与 Web Fetch