AgentCore 一次调用获取带来源的网页答案

给 AI Agent 接入联网问答，麻烦的往往不是搜索，而是搜索之后的一串工作：筛选来源、抓取正文、整理证据、生成答案，再把结论和引用对齐。AWS 宣布正式可用的 Web Answer，把这条流程封装成 Amazon Bedrock AgentCore 上的一次工具调用。

它的价值是减少检索流水线的维护成本，但代价也很明确：你把搜索和答案合成的控制权交给了托管服务。对已经使用 AWS、只想给 Agent 补上实时事实查询能力的团队，这个取舍值得认真看。

Web Answer 省掉的究竟是哪部分工作

传统联网问答通常由开发者自己串起来：调用搜索 API，判断哪些结果可信，读取并清洗网页，让模型综合回答，最后补上来源。任何一步出错，都可能出现证据不足却继续作答、内容过时，或者引用链接与结论对不上的问题。

Web Answer 接收自然语言问题，内部规划搜索，并行执行多个查询，读取关键页面核对事实；证据不够时继续搜索，最后输出带引用的答案。大白话解释，就是把「找资料并写出有出处的回答」整体交给服务。

AWS 表示，每个问题都会触发新搜索，内部模型也会获得当天日期。不过，新搜索并不保证索引已经收录最新页面，知道日期也不等于能正确判断所有内容的时效。

它与 Web Search 的分界，在于谁负责运行模型和生成答案：

• Web Search 返回排序后的 URL、标题、摘要和元数据，后续如何筛选、推理、合成，由你的模型决定。
• Web Answer 连同检索循环、答案合成和引用归属一起处理，返回可以继续使用的成品答案。

选择依据是你需要原始材料，还是需要一个已经整理好的事实回答。

两者可以共存。广泛研究需要比较材料、保留处理自由度时，用 Web Search；大任务中临时核实一个具体事实时，Web Answer 更符合它的定位。

接入时，权限边界比调用代码更重要

原文演示的前提是：已有位于 us-east-1 的 AgentCore Gateway，入站认证使用 AWS_IAM，本地安装 Python 3.10 或更高版本，以及 boto3、strands-agents、mcp、mcp-proxy-for-aws。安装命令是 pip install boto3 strands-agents mcp mcp-proxy-for-aws。

这里有两套身份，不能混为一谈。

调用者需要 bedrock-agentcore:InvokeGateway，决定谁能访问 Gateway。Gateway 的服务角色则需要 bedrock-agentcore:InvokeWebAnswer，决定 Gateway 能否调用后端工具。后者每次请求都会针对 AWS 持有的资源 arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-answer.v1 检查权限。

服务角色的信任策略允许 bedrock-agentcore.amazonaws.com 在限定账户范围内代入该角色。它不需要 bedrock:InvokeModel，因为外层 Agent 的模型使用 Agent 自己的身份运行。

下面这段代码把 Web Answer 注册为 Gateway target，解决工具发现和后端连接的问题：

import boto3

gateway_client = boto3.client("bedrock-agentcore-control", region_name="us-east-1")

target_response = gateway_client.create_gateway_target(
    name="web-answer-tool",
    gatewayIdentifier=gateway_id,
    targetConfiguration={
        "mcp": {
            "connector": {
                "source": {"connectorId": "web-answer"},
                "configurations": [{"name": "WebAnswer", "parameterValues": {}}],
            }
        }
    },
    credentialProviderConfigurations=[
        {"credentialProviderType": "GATEWAY_IAM_ROLE"}
    ],
)
target_id = target_response["targetId"]

重点看 GATEWAY_IAM_ROLE：Gateway 使用服务角色访问 Web Answer，开发者不用另外保存工具 API key。gateway_id 需要事先准备，创建后还要通过 get_gateway_target 等到状态变成 READY。

管理员也可以在 parameterValues 设置 {"domainFilter": {"include": ["bis.org"], "exclude": ["unreliable-source.net"]}}。这个过滤器约束经过该 target 的每次调用。Agent 可以进一步缩小来源范围，但不能重新放开管理员禁止的域名。

注册完成后，工具通过 Model Context Protocol（MCP）的 tools/list 暴露，通过 tools/call 调用。原文使用 Strands，也说明 LangChain、LangGraph、CrewAI 或其他兼容 MCP 的客户端可以接入。

返回引用以后，应用层还要处理什么

原文的外层 Agent 使用 BedrockModel(model_id="us.anthropic.claude-sonnet-5", max_tokens=1024)，发现的工具名为 web-answer-tool___WebAnswer。这个模型配置属于调用工具的 Agent，原文没有披露 Web Answer 内部使用的模型。

每次调用除了问题，还可以传入域名过滤、发布日期范围和国家参数。原文没有给出后两者的具体字段名，接入时不能凭描述猜参数。

响应同时提供 content 和 structuredContent。前者是文本结果，答案以 Markdown 表达，带有 [1] 这样的引用标记；后者的 structuredContent.answer 通常包含一个答案块，同时携带引用列表，每条引用包含来源 URL，以及可用时的域名。

对于要展示答案的前端，这个结构很实用：正文与来源列表可以分别处理，不必只依赖正则从 Markdown 中提取链接。不过，外层 Agent 如果继续改写答案，仍需关注结论与引用是否保持对应。工具提供了引用，不代表后续加工天然不会破坏归属关系。

原文示例的 _meta.latencyMs 为 5210，isError 为 false。这只是一个响应示例，不能拿来当平均延迟、P95 或服务承诺。

部署约束也需要一起算进去：文章称服务当前仅在 US East（N. Virginia），即 us-east-1 可用；每账户限额为每秒 10 次事务，提额需要联系 AWS Support。Web Answer 每 1,000 次工具调用收费 10 美元，即单次 0.01 美元，Gateway 调用另行计费，外层 Agent 模型也要单独考虑成本。

资源不用时，应调用 delete_gateway_target 删除 target；如果 Gateway 仅为演示创建，还要先删除其 targets，再通过 delete_gateway 删除 Gateway，最后移除服务角色及策略。

我的判断

我认可它解决的问题：联网问答中的大量工作属于基础设施维护，未必值得每个业务团队重复实现。对于已有 AgentCore Gateway 的团队，统一认证、工具发现和域名边界，比额外接入一套搜索凭据更顺手。

但这篇文章提供的是接入演示，没有给出与自建流水线、Web Search 或其他服务的准确率、引用正确率、延迟和成本对照。AWS 提到负责式 AI 防护经过设计与测试，也没有披露具体测试结果。因此，「更省维护」有明确的架构依据，「回答质量更好」则缺少比较证据。

带引用的答案更方便核验，但引用本身不能证明结论正确。

尤其是监管、医疗、法律等原文列出的场景，链接存在、来源权威、证据支持具体结论，是三个不同的问题。

数据边界方面，AWS 声称查询和结果留在 AWS 环境内，搜索使用 Amazon 运营的网页索引和知识图谱，不向第三方搜索引擎或外部网站发送问题。Gateway 还支持通过 VPC 接口端点 com.amazonaws.us-east-1.bedrock-agentcore.gateway 访问，并提供 CloudWatch 指标。这些是有价值的控制能力，但不能仅凭博客中的「Zero data egress」就推定所有日志、存储和保留细节，文章没有展开这些内容。

如果团队需要控制网页清洗、材料排序、提示词或模型选择，Web Search 仍然更合适。Web Answer 的便利，来自接受这一部分实现由 AWS 决定。

能拿来做什么

• 已经使用 AgentCore 的团队，可以先选一个范围明确的事实查询任务试接 Web Answer，并用现有问题比较答案是否有用、引用是否支持结论，以及完整调用成本。
• 为客服或公开政策问答配置 target 时，可以先由管理员限定可信域名，再让 Agent 按问题缩小范围，避免把来源约束完全交给模型临时决定。
• 前端展示答案时，可以利用 structuredContent.answer 及其引用列表组织正文和来源入口，同时检查外层 Agent 改写后的引用是否仍然对应原结论。
• 需要广泛研究和自行综合材料时，可以继续使用 Web Search；只在需要具体、带出处的事实答案时调用 Web Answer，并结合每账户 10 TPS 的限制安排并发。