Amazon Bedrock AgentCore 的 Web Search 现在支持在运行时按域名和发布日期过滤搜索结果。开发者可以针对每一次请求决定智能体允许查询哪些网站、内容需要新到什么程度，而且这些约束由服务端执行。与此同时，Web Search 的可用区域扩展到了欧洲（爱尔兰）和亚太（东京）。
从固定搜索策略变成逐请求控制
这次更新的关键不是“又多了两个搜索参数”，而是过滤条件进入了请求级控制面。同一个智能体可以根据当前任务采用不同的检索边界，而不必复制工具、维护多套 Agent 配置，或者完全依赖提示词约束来源。
例如，一个企业知识助手可能同时处理三类问题：
- 查询 AWS 产品变化时，只允许访问官方文档和公告域名。
- 汇总行业新闻时，放宽域名范围，但只接收最近 7 天发布的内容。
- 调查历史事件时，不设置较短的时间窗口，避免过滤掉必要资料。
这种控制粒度适合多租户系统。应用可以根据租户策略、用户角色或任务类型，在调用 Web Search 时动态生成过滤条件。
服务端过滤比提示词约束更可靠
过去常见的做法是在系统提示词中写入“只参考官方网站”或“只使用最近一个月的信息”。这种指令仍然有价值，但它属于模型行为约束，不等同于检索系统的强制边界。
运行时过滤由服务端执行，意味着不符合域名或发布日期要求的来源会在搜索层被排除。这样可以减少两个问题：一是模型看到不合规来源后仍然引用它；二是应用在拿到搜索结果后自行过滤，浪费请求延迟和上下文窗口。
不过，域名过滤不能自动证明内容正确，发布日期过滤也不能保证信息仍然有效。生产系统仍应保留引用展示、结果审计和高风险回答的人工确认机制。
可以这样实践：在应用层生成逐请求策略
下面是一个可直接运行的 Python 示例，用于根据任务类型生成 Web Search 过滤策略。由于来源摘要没有给出 AgentCore SDK 的确切字段名，示例中的 domainFilters、publishedAfter 和 HTTP 路径属于集成假设；接入时需要按当前 AgentCore API 或 SDK 文档替换，但策略生成、日期计算和请求结构可以直接改造。
运行前设置实际端点与访问令牌：
export AGENTCORE_WEB_SEARCH_URL='https://your-agentcore-endpoint.example/web-search'
export AGENTCORE_TOKEN='replace-with-your-token'
pip install requests
创建 search_with_policy.py：
import os
from datetime import datetime, timedelta, timezone
import requests
def build_filters(task_type: str) -> dict:
now = datetime.now(timezone.utc)
if task_type == "aws_release":
return {
"domainFilters": {
"allow": ["aws.amazon.com", "docs.aws.amazon.com"]
},
"publishedAfter": (now - timedelta(days=30)).date().isoformat(),
}
if task_type == "industry_news":
return {
"publishedAfter": (now - timedelta(days=7)).date().isoformat()
}
return {}
def web_search(query: str, task_type: str) -> dict:
url = os.environ["AGENTCORE_WEB_SEARCH_URL"]
token = os.environ["AGENTCORE_TOKEN"]
payload = {
"query": query,
"filters": build_filters(task_type),
}
response = requests.post(
url,
headers={
"Authorization": f"Bearer {token}",
"Content-Type": "application/json",
},
json=payload,
timeout=30,
)
response.raise_for_status()
return response.json()
if __name__ == "__main__":
result = web_search(
"What changed recently in Amazon Bedrock AgentCore?",
"aws_release",
)
print(result)
执行：
python search_with_policy.py
这里应把策略选择留在服务端业务代码中，不要允许浏览器客户端任意传入允许域名。否则，调用者可能绕过组织规定的来源边界。更稳妥的方式是让客户端提交 task_type，再由后端把它映射为经过审核的域名集合和时间窗口。
日期过滤需要定义清楚业务语义
“最近 7 天”看似简单，落地时仍有几个边界需要处理：
- 统一使用 UTC 计算截止日期，避免部署区域和用户时区造成结果漂移。
- 明确过滤依据是网页首次发布日期、更新时间，还是搜索服务识别出的发布日期。
- 为没有可靠发布日期的页面制定策略：排除、降权，或允许但标记日期未知。
- 不要把发布日期当成事实有效期。新发布的页面也可能引用旧数据。
对于审计要求较高的系统，可以记录每次请求的查询文本、域名规则、日期边界、部署区域以及最终引用来源，但应避免把令牌或敏感用户输入写入日志。
区域扩展带来的部署选择
Web Search 现已扩展到欧洲（爱尔兰）和亚太（东京）区域。对已经在这些区域运行 AgentCore 工作负载的团队，这能提供新的同区域部署选择，并可能简化延迟、架构和数据治理方面的决策。
上线前仍需核对具体区域中的模型、AgentCore 能力、配额和组织合规要求是否完整匹配。Web Search 可用并不代表整个智能体依赖链都能在同一区域运行。
上线检查清单
采用新过滤能力时，可以重点检查以下事项：
- 为每类任务维护经过审核的域名允许列表，而不是接受任意用户输入。
- 使用请求级日期窗口，并统一时区与边界日期计算方式。
- 对无结果场景提供明确降级策略，不要静默取消过滤条件。
- 在回答中保留来源引用，让用户能够检查内容和发布日期。
- 分别验证欧洲（爱尔兰）与亚太（东京）区域的能力、配额和端到端延迟。
- 记录生效的过滤策略，便于复现错误回答和执行合规审计。
这项更新最适合被当作检索治理能力，而不只是搜索体验优化。把域名和发布日期规则放进后端策略层，再通过每次 AgentCore Web Search 请求执行，才能让智能体的来源范围既灵活，又可检查、可复现。