navflow/navflow-cookbooks

# NavFlow 实战手册 这是对模型提供商（Anthropic、OpenAI 等）发布的 agent 实战手册的配套补充。每一篇都选取一个已发布的 agent，保持其原样，并**仅替换其读取路径**为 NavFlow —— 然后在真实运行的系统上测量差异。 核心在于：按照提供商方式构建的 agent 会在每一步中分散调用许多工具来收集上下文。NavFlow 只需摄取这些源一次，就能向 agent 提供单一的、关联的查询（并且可以在已附加上下文的情况下触发它）。相同的 agent，相同的答案，但调用次数大大减少。 ## 布局 ``` navflow/ ← reusable in-process NavFlow simulation, shared by every cookbook dataplane.py the "dummy" data plane: register sources, define a view, consolidate mcp.py serve a view to the agent as one MCP `query` tool triggers.py the push half: watch a condition, hand back the correlated view platform/ ← the deployable demo system you run agents against app/api_server.py multi-lever fault-injecting API server (FastAPI + Prometheus) docker-compose.yml, prometheus.yml, grafana/ one-command local stack cookbooks/ ← one dir per cookbook 01_sre_incident_response/ Anthropic's SRE agent vs the NavFlow read path ``` `navflow/` 和 `platform/` 只需编写一次，即可被所有实战手册复用。NavFlow 的读取路径运行在**进程内** —— 无需外部服务，因此整个系统是自包含的。创建新的实战手册主要包括：定义其源/视图，将 baseline agent 和 NavFlow agent 指向同一个事件并进行测量。 ## 平台：一个系统，多个可注入的事件 Anthropic 的 SRE 演示仅公开了一个控制参数（DB 连接池大小），因此它只能模拟一个事件。我们的平台保持了同样简洁的 Prometheus 指标格式和 Grafana 仪表板，但 API 服务器公开了多个**独立**的故障，每个故障都有可区分的指标、日志和一个“部署”变更日志条目（即 SRE agent 所需的关联信号）： | 事件 | 控制参数 | 表现形式 | |---|---|---| | DB 连接池耗尽 | `db_pool_size` | 连接池耗尽日志，`db_connections_active` 居高不下，`/api/users` 出现 500 错误 | | 延迟劣化 | `inject_latency_ms` | p99 飙升，连接池健康，无错误日志 | | 错误激增（错误部署） | `error_rate` | app-exception 日志，DB 健康 | | 依赖项中断 | `dependency_down` | `dependency_up{...}=0`，`/api/orders` 上出现“upstream unreachable”日志 | 在运行时注入和清除，无需重新部署： ``` curl -XPOST localhost:8080/admin/fault -d '{"lever":"db_pool_size","value":1}' curl -XPOST localhost:8080/admin/fault -d '{"lever":"inject_latency_ms","value":800}' curl -XPOST localhost:8080/admin/fault -d '{"lever":"dependency_down","value":"payments-api"}' curl -XPOST localhost:8080/admin/reset curl localhost:8080/admin/config # the current config an agent inspects curl localhost:8080/admin/changelog # recent "deploys" — the root-cause correlation ``` ## 每本实战手册的对比内容 - **Baseline** —— 提供商的 agent，将每个源都封装为单独的工具（读取路径的扇出）。 - **NavFlow 读取路径** —— 同一个 agent，将其工具替换为一个 `query(view, key, window)`。 - **NavFlow 触发** —— 由 NavFlow 唤醒的 agent，并且已经附加了关联的时间线。 ……所有这些都针对同一个注入的事件，并测量读取调用 / 轮次 / 成本 / 准确度。 ## 状态 - [x] `platform/` —— 多控制参数的故障注入 API 服务器 + docker-compose（Prometheus、Grafana、流量生成器） - [x] `navflow/` —— 可复用的进程内数据平面模拟 + MCP 服务器 - [x] `cookbooks/01_sre_incident_response/` —— baseline + NavFlow agent、触发器、`run.py` / `report.py` - [ ] 更多实战手册（其他提供商 / 用例） 请参阅 [`cookbooks/01_sre_incident_response/README.md`](cookbooks/01_sre_incident_response/README.md) 获取首个演示指南。 ## 许可证 Apache License 2.0 —— 详见 [`LICENSE`](LICENSE)。

标签：AI智能体, API集成, AV绕过, DLL 劫持, FastAPI, MCP, SRE运维, 可观测性, 大语言模型, 故障注入, 版权保护, 自定义请求头, 请求拦截, 逆向工具