用 LangGraph 自动追踪依赖动态

每天盯 npm 依赖、Python 包和容器基础镜像，难点不只是搜到新消息，还要判断消息有没有证据、是不是重复提醒，以及模型会不会擅自放宽检索条件。AWS 这篇教程搭了一个日常依赖巡检：用 LangGraph 并行研究，用 AgentCore Web Search 获取来源，再由代码校验和去重。

最值得借鉴的是职责划分：模型负责找线索，代码负责守规则。作者实测把三个分支的累计耗时从 99 秒压到 36 秒，但它仍是线索筛选器，不能直接充当漏洞裁决系统。

为什么搜索条件不能交给模型

模型的训练数据回答不了「今天新增了什么」。Amazon Bedrock AgentCore 的 Web Search API 提供实时网页结果，每条包含标题、URL、发布日期和与查询相关的摘录，并支持域名包含、排除及发布日期过滤。

按原文说明，查询由 Amazon 自营索引处理，不会转发给第三方搜索引擎。接口使用现有 AWS 凭证，通过 AWS Signature Version 4（SigV4）签名；应用部署在 AWS Lambda、Amazon ECS 或 AgentCore runtime 时，可以直接使用执行角色，无须另存和轮换搜索 API key。

这解决了接入和凭证管理问题，但搜索范围仍要由应用控制。示例给每个研究分支单独创建工具，把黑名单、时间下限和次数预算固定下来：

toolkit, tools = create_web_search_toolkit(
    region="us-east-1",
    exclude_domains=BLOCKLIST,
    published_after=window_start.strftime("%Y-%m-%dT%H:%M:%SZ"),
    model_filters=False,
    max_searches=4,
    return_sources=True,
)

重点看 model_filters=False：模型只能提交查询词，不能自行选择过滤条件。max_searches=4 限制每个分支最多搜索四次，return_sources=True 则让结果同时以文本和结构化附件（artifact）返回，分别交给模型阅读、交给代码核验。

必须始终成立的规则，应由每次调用都会经过的代码执行。

原文接口支持日期区间，但这段配置只展示了 published_after 下限；最终是否落在完整巡检窗口内，还要由后面的证据检查确认。

运行环境要求 Python 3.10 或更高版本，以及以下依赖：

pip install -U "boto3>=1.43.127" "bedrock-agentcore>=1.26.0" "langchain-aws[tools]>=1.9.3" langchain langgraph

这里要留意最低版本，尤其是 langchain-aws[tools]>=1.9.3。示例区域为 us-east-1，调用身份还需要访问 Amazon Bedrock 中的 Anthropic Claude 模型，并获得 bedrock-agentcore:InvokeWebSearch 权限，对应资源是 arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-search.v1。

36 秒跑完之后，哪些结果才有资格进入日报

巡检由 watchlist 和时间窗口启动。fan_out 使用 LangGraph 的 Send API，为 npm、PyPI、容器基础镜像各开一个并行分支。每个分支调用 Anthropic Claude，自行决定查询词，最终通过 create_agent 和 Pydantic schema 返回结构化发现。

这些发现包含包名、标题、CVE 或公告 ID、来源声明的严重程度、是否已被利用、建议动作和来源 URL。结构化输出方便处理，却不代表字段已经真实可靠。

因此，每个分支返回前，代码逐条检查：

• 引用 URL 必须出现在该分支实际拿到的搜索结果中。
• 来源标题或正文必须以完整单词形式出现包名。
• 发现中的 CVE 或公告 ID 必须出现在来源文本中。
• 来源发布日期必须落在巡检窗口内，缺失日期直接淘汰。

检查依赖的是程序保留的原始来源数据。让模型再回答一次「这个结论有没有依据」，不能替代这一步。

作者用 7 天窗口实测，三个分支共执行 12 次搜索，得到 80 个来源。并行墙钟时间为 36 秒，三个分支耗时相加为 99 秒。证据检查剔除了两条发现：一条来源没提到包名，另一条来源没有对应 CVE ID；返回来源中也没有命中被屏蔽域名。

最终四条通过检查，keep_new 查询 LangGraph store 后只报告两条，因为另外两条在此前测试中已经发过。第二次运行又留下两条发现，但都已报告，所以日报没有新增内容。

这证明了示例中的并行、筛选和去重流程可以工作，没有证明漏洞识别的准确率。原文也明确说，这四项检查不核实严重程度、利用状态、受影响版本和修复建议，更不能证明首次披露时间。索引标成最近发布的页面，也可能在讲旧事件。

每天运行和跨团队复用，需要补哪几层

去重能否持续生效，首先取决于存储。InMemoryStore 只适合演示；定时任务应换成支持精确键查询的持久化存储，例如 langgraph-checkpoint-aws 提供的 DynamoDBStore。AgentCore runtime 的会话状态也是临时的，部署上去不会自动解决跨天记忆问题，还需要调度和持久化。

Runtime 支持原有 LangGraph 图，无须改写框架。默认 MicroVMs 为每个会话提供独立隔离环境；Instances 使用自己 AWS 账户中的托管 Amazon EC2 实例，适合多日会话、GPU 或多个 Agent 共享实例。示例通过 agentcore invoke 调用 Runtime。

搜索入口则按规则归谁管理来选。单个应用自己调用、自己执行规则，直接使用 Web Search API 即可。平台团队要给多个 Agent 或 MCP 客户端统一施加来源策略，则更适合 AgentCore Gateway。

Gateway 把管理员策略放在搜索 target 上，模型看不到，也不能解除。此时有两套身份权限：Gateway 服务角色需要 bedrock-agentcore:InvokeWebSearch，Agent 的签名身份需要 bedrock-agentcore:InvokeGateway。不同团队可以各建一个搜索 target，配置各自的黑名单。

扩容前还有几个具体约束：默认配额是每账户、每区域每秒 10 个请求，多个 Agent 共享；工具默认名为 web_search，已有同名工具时要改名；不同预算或过滤规则需要独立 toolkit。搜索区域可以与模型所在区域不同。

已有 Deep Agents 应用可通过 create_deep_agent 把工具传入子 Agent，再在输出或 middleware 中加入证据检查。作者测试中，协调 Agent 委派研究子 Agent 后，约一分钟返回带引用的答案。

搜索和模型调用均按量计费。演示前六步不创建 AWS 资源，Gateway 和 Runtime 则涉及部署清理。原文给出 DELETE_GATEWAY = True、agentcore remove all，随后又列出 agentcore deploy -y；最后这个命令会部署，不能不加辨别地当作纯清理流程照抄。

我的判断

我赞同它把「研究」和「验收」分开。模型适合生成查询、整理候选发现；域名限制、日期判断、预算和去重交给确定性代码，行为更容易追踪。来源同时保存在模型上下文之外，也让后续校验有了独立依据。

但通过这些检查，只能说明部分字段找得到出处。原文没有给出与权威漏洞源、固定订阅或传统脚本的准确率、召回率和成本对照，也没说明去重键如何设计。相同公告后来更新受影响版本或修复建议时，会不会被当成旧消息压掉，需要另行处理。

对生产安全流程，网页搜索适合补充线索，最终判断仍要回到权威漏洞源。

如果只监控固定包、固定公告站，订阅和规则脚本可能更容易维护。需要跨生态、跨站点追踪零散消息时，Agent 的查询灵活性才更有价值。36 秒对 99 秒是这次运行的结果，不能据此推断换个团队也有相同收益。

能拿来做什么

• 前端团队可以从实际使用的 npm 包建立 watchlist，固定查询窗口和搜索预算，先把结果做成带来源的候选日报，再接入权威漏洞源核验。
• 全栈团队可以按 npm、PyPI、容器基础镜像拆分独立分支，并为每个分支单独配置 toolkit，避免并行研究共享预算时互相挤占。
• 给日常 AI 编程助手增加搜索能力时，应保留来源 artifact，并检查引用 URL、包名和公告 ID；展示给用户的结果也要保留引用，这是原文提到的使用条款要求。
• 把巡检改成每日任务前，应先实现持久化去重，并明确公告更新是否需要重新提醒，再配置调度、共享配额和人工复核流程。