MITM 抓包代理的实现方案：从用户态代理到驱动层
六种实现层次对比方案 典型工具 特点用户态代理 mitmproxy, Charles, Burp Suite 配置简单，需安装根证书TUN 虚拟网卡 Clash Meta, sing-box, Surge 不依赖系统代理，可抓 UDP/游戏WinDivert WinDivert + 自定义程序 Windows 驱动层，游戏加速器常用WFP 企业安全/DLP 产品 微软官方，性能高，不易检测NDIS Filter Wireshark/Npcap 二层帧，可抓所有流量Socket Hook Frida, Xposed 拦截加密前明文，绕过证书绑定用户态代理（最常见） 流量路径： App → 系统代理 → MITM Proxy → 目标服务器HTTPS 需要：生成 CA 根证书，安装到系统信任 收到 CONNECT hostname:443 后，动态签发 hostname 的域名证书 与客户端建立一条 TLS，与服务端建立另一条 TLS，在中间解密/重新加密TUN 虚拟网卡方案 App → 虚拟网卡(TUN) → 用户态协议栈 → 真实网卡Linux 创建 TUN： int tun_fd = open("/dev/net/tun", O_RDWR); // 配置后：所有流量走 TUN，用户态读 IP 包 read(tun_fd, buf, sizeof(buf));优点：不需要配系统代理，UDP 也能抓，Clash/sing-box 都用这套。 Python 实现最小 HTTPS MITM 第一步：生成 CA openssl genrsa -out ca.key 2048 openssl req -x509 -new -key ca.key -out ca.crt -days 3650安装 ca.crt 到系统根证书信任。 第二步：动态签发域名证书 from cryptography import x509 from cryptography.x509.oid import NameOID from cryptography.hazmat.primitives import hashes, serialization from cryptography.hazmat.primitives.asymmetric import rsa import datetimedef gen_cert(hostname: str, ca_key, ca_cert): key = rsa.generate_private_key(public_exponent=65537, key_size=2048) cert = ( x509.CertificateBuilder() .subject_name(x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, hostname)])) .issuer_name(ca_cert.subject) .public_key(key.public_key()) .serial_number(x509.random_serial_number()) .not_valid_before(datetime.datetime.utcnow()) .not_valid_after(datetime.datetime.utcnow() + datetime.timedelta(days=365)) .add_extension(x509.SubjectAlternativeName([x509.DNSName(hostname)]), critical=False) .sign(ca_key, hashes.SHA256()) ) return key, cert第三步：TLS 劫持 import ssl# 客户端侧：用伪造证书与客户端握手 def mitm_tls_client(client_socket, hostname, certfile, keyfile): ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) ctx.load_cert_chain(certfile, keyfile) return ctx.wrap_socket(client_socket, server_side=True)# 服务端侧：正常连接真实服务器 def connect_server(hostname, port): ctx = ssl.create_default_context() raw = socket.create_connection((hostname, port)) return ctx.wrap_socket(raw, server_hostname=hostname)两端建立后，中间就能读到明文 HTTP 请求： req = client_tls.recv(8192) print(req.decode()) # POST /v1/chat/completions ...HTTP 解析推荐 不要手动解析 HTTP，使用成熟库： pip install h11 # 轻量，推荐 # 或 pip install httptools证书缓存 对同一域名动态生成一次后缓存，避免每次重复生成： cert_cache = {}def get_cert(hostname): if hostname not in cert_cache: key, cert = gen_cert(hostname, ca_key, ca_cert) cert_cache[hostname] = (key, cert) return cert_cache[hostname]最小模块划分 自己实现一个基础 HTTPS MITM 代理，核心代码约 500~1000 行： proxy/ ├── listener.py # 监听连接 ├── connect.py # 处理 CONNECT 方法 ├── tls.py # TLS 劫持 ├── cert.py # 动态证书生成/缓存 ├── http.py # HTTP 解析 └── logger.py # 请求日志局限性 用户态 HTTP Proxy 在以下场景会遇到问题：QUIC/HTTP3（基于 UDP，不走 CONNECT） App 硬编码不走系统代理 Certificate Pinning（固定证书哈希） gRPC over HTTP2对于需要捕获所有流量的场景（如 AI Agent 全局监听），TUN + gVisor Netstack 扩展性更好。
2026 年 AI Agent 框架选型：LangGraph、Mastra、PydanticAI 对比与 LangGraph 最小实现
框架横向对比（2026）框架 语言 适合场景LangGraph Python 生产环境、多 Agent、长流程Mastra TypeScript Next.js 全栈项目PydanticAI Python FastAPI、结构化输出CrewAI Python 多角色协作 AgentAutoGen Python 研究方向、自动代码执行OpenAI Agents SDK Python 轻量 Tool Calling、OpenAI 为主综合推荐排名：LangGraph > OpenAI Agents SDK > Mastra > PydanticAI > CrewAI > AutoGen LangGraph：生产首选 LangGraph 基于状态机（StateGraph），天然支持：循环图（Think → Act → Observe → Think） Checkpoint 持久化 Multi-Agent（Supervisor / Swarm） Human-in-the-Loop（Interrupt + Resume） 与 Playwright/Browser Use 集成大量生产环境已从 LangChain Agent 迁移至 LangGraph。 LangGraph 最小实现 pip install langgraph langchain-openai langchain-coretools.py： from langchain_core.tools import tool import subprocess@tool def search(query: str) -> str: """搜索信息""" return f"搜索结果: {query}"@tool def shell(command: str) -> str: """执行命令""" try: return subprocess.check_output(command, shell=True, text=True, timeout=5)[:5000] except Exception as e: return str(e)app.py： from typing import TypedDict from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage, ToolMessage from tools import search, shellllm = ChatOpenAI(model="gpt-4o") tools = [search, shell] llm_with_tools = llm.bind_tools(tools)class AgentState(TypedDict): messages: listdef agent_node(state): response = llm_with_tools.invoke(state["messages"]) return {"messages": state["messages"] + [response]}def tool_node(state): last = state["messages"][-1] tool_messages = [] for call in last.tool_calls: result = search.invoke(call["args"]) if call["name"] == "search" else shell.invoke(call["args"]) tool_messages.append(ToolMessage(content=str(result), tool_call_id=call["id"])) return {"messages": state["messages"] + tool_messages}def should_continue(state): last = state["messages"][-1] return "tool" if hasattr(last, "tool_calls") and last.tool_calls else ENDgraph = StateGraph(AgentState) graph.add_node("agent", agent_node) graph.add_node("tool", tool_node) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue, {"tool": "tool", END: END}) graph.add_edge("tool", "agent") app = graph.compile()运行： result = app.invoke({"messages": [HumanMessage(content="列出当前目录")]}) print(result["messages"][-1].content)Agent Memory 分级架构 高 Token 消耗的核心问题是全量注入记忆。推荐分三级： L1 工作记忆 → 最近 10~20 条消息，直接进 Prompt L2 任务记忆 → 当前项目/任务相关，按需读取 L3 长期记忆 → 用户偏好、历史经验，向量检索 TopKMemory Router 方案 不让 Memory 全量注入，而是先路由： def memory_router(state): query = state["query"] if "合约" in query: return {"memory_keys": ["web3"]} if "SpringBoot" in query: return {"memory_keys": ["coding", "project"]} return {"memory_keys": []}再根据 memory_keys 去向量库检索 Top-K 相关记忆注入 Prompt。 推荐存储方案 Redis → L1 短期记忆（最近消息、任务状态） pgvector → L2/L3 长期记忆（向量检索） Qdrant → 替代 pgvector（独立向量库）这样单次请求上下文通常能从 50k+ Token 压到 3k~10k Token，且效果往往更好（减少无关记忆干扰）。 OpenClaw 与 LangGraph 的关系 OpenClaw 是一个 Agent Runtime（Agent 操作系统），包含 Gateway（消息入口）、Skills（工具插件）、Memory、Workspace。LangGraph 提供了其中 Agent Loop + Persistence + Multi-Agent 的核心能力，但不负责 Gateway 和 Tool 生态。 用 LangGraph 可以实现 OpenClaw 绝大部分核心功能，真正耗工程量的是：权限系统、Tool 生态、Browser 自动化和可观测性系统。 最小技术栈（个人项目） Next.js / SpringBoot → 前后端 LangGraph → Agent 编排 Redis → 短期记忆 Postgres + pgvector → 长期记忆 Playwright → 浏览器操作 Quartz / @Scheduled → 定时任务
2026 年 AI Agent 框架选谁：LangGraph / Mastra / PydanticAI 对比
2026 年做 AI Agent / 自动化助手 / 工具编排，可选的框架不少。按技术栈和使用场景推荐。 一句话选型场景 / 栈 首选生产级多 Agent、复杂流程 LangGraphNext.js / TypeScript 栈 MastraPython + 类型安全 PydanticAI多角色协作模拟 CrewAI微软生态 AutoGen轻量 + 只用 OpenAI OpenAI Agents SDKLangGraph（生产级首推） LangGraph 是 LangChain 团队的新一代框架——基于状态机而不是 chain，比传统 LangChain Agent 稳定很多。 核心概念：一个 Agent 是一张有向图，节点是"要做什么"，边是"下一步去哪儿"。 from langgraph.graph import StateGraphdef planner(state): return {"plan": llm(state["query"])}def executor(state): return {"result": tool_call(state["plan"])}graph = StateGraph(dict) graph.add_node("plan", planner) graph.add_node("execute", executor) graph.add_edge("plan", "execute") graph.set_entry_point("plan") app = graph.compile()app.invoke({"query": "帮我订机票"})优势：显式状态机、执行流程可视化 支持 Human-in-the-Loop（中断、审核、恢复） 支持 checkpoint 持久化 复杂 workflow 也能表达 生产环境案例最多——很多公司已经从 LangChain Agent 迁到 LangGraph缺点：学习曲线不低，Python + TS 双语言。 Mastra（Next.js 生态首选） Mastra 是全 TypeScript 的 Agent 框架，跟 Vercel AI SDK 生态贴合。 import { Agent } from "@mastra/core"; import { openai } from "@ai-sdk/openai";const agent = new Agent({ name: "Assistant", model: openai("gpt-5"), tools: [webSearch, calculator], });const result = await agent.text("北京今天多少度？");优势：TS 全栈，类型贯穿 Agent / Workflow / Memory / RAG 一站式 部署到 Vercel / Cloudflare Workers 都方便 学习曲线比 LangGraph 低适合：Next.js 项目里直接嵌 Agent、Vercel/Cloudflare 部署、快速迭代。 PydanticAI（Python 类型党） PydanticAI 是 Pydantic 团队做的——Structured Output 特别强，走类型驱动。 from pydantic_ai import Agent from pydantic import BaseModelclass Answer(BaseModel): city: str temp: float condition: stragent = Agent("openai:gpt-5", result_type=Answer)result = agent.run_sync("北京今天多少度？") print(result.data.city, result.data.temp) # 强类型输出优势：输出直接是 Pydantic 模型，编辑器自动补全 支持 OpenAI / Anthropic / Google / Ollama 依赖注入优雅 适合科研 / 数据分析 / 代码 AgentCrewAI（多 Agent 协作） CrewAI 把 Agent 组织成"团队"，每个 Agent 有角色： from crewai import Agent, Task, Crewresearcher = Agent(role="研究员", goal="找资料") writer = Agent(role="写作", goal="写报告") reviewer = Agent(role="审校", goal="审核")task1 = Task(description="研究 xxx", agent=researcher) task2 = Task(description="写报告", agent=writer) task3 = Task(description="审核", agent=reviewer)crew = Crew(agents=[researcher, writer, reviewer], tasks=[task1, task2, task3]) crew.kickoff()适合：复杂业务流程模拟——产品-开发-测试-运维流水线；市场调研 → 分析 → 报告。 缺点：抽象层多、开销较大、生产环境案例不如 LangGraph。 AutoGen（微软） AutoGen 强项在多 Agent 对话： from autogen import AssistantAgent, UserProxyAgentassistant = AssistantAgent("assistant", llm_config={...}) user = UserProxyAgent("user", code_execution_config={...})user.initiate_chat(assistant, message="写个爬虫爬 GitHub trending")Agent 之间"对话"完成任务，还能自动执行代码。学习曲线较高，生产环境案例相对少。 OpenAI Agents SDK OpenAI Agents SDK 是 OpenAI 官方的轻量 Agent 框架： from agents import Agent, Runneragent = Agent( name="Helper", instructions="回答问题", tools=[web_search, calculator], )result = Runner.run_sync(agent, "北京今天多少度？")适合：只用 OpenAI 模型 + 简单场景。想接 Claude / Gemini 就得考虑其它。 对比矩阵框架 语言 状态管理 多 Agent 生产案例 学习曲线LangGraph Python/TS 状态机 ✅ 最多 中偏难Mastra TypeScript 简单 ✅ 中 低PydanticAI Python 简单 有限 中 低CrewAI Python 简单 ✅ 中 低AutoGen Python 对话 ✅ 少 高OpenAI SDK Python 简单 有限 少 极低建议一开始就要上生产、多 Agent、需要审核流程 → LangGraph 和 Next.js 网站集成、要部署到 Vercel → Mastra 科研 / 数据分析、追求类型安全 → PydanticAI 只做 demo / 内部工具、就用 OpenAI → OpenAI Agents SDK 要模拟一个团队协作 → CrewAIMCP 生态 不管选哪个，都建议同时接入 MCP（Model Context Protocol）——一层协议，让所有 Agent 框架能共享工具（Context7、Playwright MCP、Slack MCP 等）。所有主流框架都有 MCP client 支持。 一句话总结 LangGraph 是当前生产 Agent 的最佳选择。TS 栈用 Mastra、Python 类型党用 PydanticAI、多角色模拟用 CrewAI。Agent 生态在 MCP 出来后开始有统一入口，选框架同时接 MCP 是长期正确的方向。
Redis 在 Windows 上注册为系统服务的两种方式
Redis 官方本身不出 Windows 版，只能靠社区移植版或者 WSL / Docker。想让它随开机启动，两条路。 方式一：tporadowski 移植版自带的服务参数 先下载 tporadowski/redis 的 zip，解压到 D:\Redis，目录里应该有： redis-server.exe redis-cli.exe redis.windows.conf管理员打开 CMD： cd /d D:\Redis redis-server.exe --service-install redis.windows.conf --service-name Redis redis-server.exe --service-start查看服务状态： sc query Redis或者 services.msc 里能看到"Redis"服务。 设置自动启动（默认就是）： sc config Redis start= auto注意 start= 和 auto 之间必须有空格。 测试： redis-cli.exe ping返回 PONG 说明装好了。 停止 / 卸载： redis-server.exe --service-stop redis-server.exe --service-uninstall版本不支持 --service-install 的情况 装某些新版本时（例如 Redis 7.4.x 的某些 Windows 编译版）执行 --service-install 会报： *** FATAL CONFIG FILE ERROR (Redis 7.4.7) *** Reading the configuration file, at line 2 >>> 'service-install "redis.conf"' Bad directive or wrong number of arguments原因：这个版本不支持 --service-* 参数，redis-server.exe 直接把 --service-install 当成配置项塞进 conf 里解析，才报"错误指令"。 验证一下： redis-server.exe --help帮助里没有 --service-install / --service-start 就说明确实不支持。这时候上方式二。 方式二：NSSM 包装（通用兜底） NSSM 是个通用的 "把任何程序包成 Windows 服务" 的小工具。 管理员 CMD： nssm install redis弹出 GUI，填三项： Path: D:\Redis\redis-server.exe Startup directory: D:\Redis Arguments: D:\Redis\redis.conf保存后： nssm start redis日志、重启策略、依赖都能在 NSSM 里配。 验证 Redis 真的在监听 netstat -ano | findstr 6379看到： TCP 0.0.0.0:6379 LISTENING就通了。 一句话总结 有 --service-install 就用它、没有就用 NSSM，Windows 上把 Redis 装成开机服务这事就这两条路。
Redis Windows 安装为系统服务：service-install 命令与 Bad directive 报错修复
安装 Redis 为 Windows 服务 将 Redis 解压到目录（如 D:\Redis），管理员身份打开 CMD： cd /d D:\Redisredis-server.exe --service-install redis.windows.conf --service-name Redis注意：配置文件必须用 redis.windows.conf，不能用 redis.conf。 启动服务： redis-server.exe --service-start停止服务： redis-server.exe --service-stop卸载服务： redis-server.exe --service-uninstall验证连接： redis-cli.exe ping # 返回 PONG 表示成功查看 Redis 是否在监听： netstat -ano | findstr 6379报错：Bad directive *** FATAL CONFIG FILE ERROR (Redis 7.4.x) *** Reading the configuration file, at line 2 >>> 'service-install "redis.conf"' Bad directive or wrong number of arguments原因：Redis 7.x 对 --service-install 参数解析方式改变，直接写 redis.conf 会被误解析为配置文件内容。 修复方案：使用 Redis Windows 专用配置文件 redis.windows.conf（发行包中已包含）： redis-server.exe --service-install redis.windows.conf --service-name Redis如果发行包只有 redis.conf，复制一份并重命名为 redis.windows.conf 即可。 设置开机自启 安装服务后默认为自动启动，查看启动类型： sc qc Redis若不是 AUTO_START，手动设置： sc config Redis start= auto注意 start= 后面必须有一个空格。 查看服务状态（或在 services.msc 图形界面查找 "Redis"）： sc query RedisNSSM 替代方案 NSSM（Non-Sucking Service Manager）适合管理任何 exe 为 Windows 服务，不依赖 Redis 自带的 service 参数： nssm install Redis在弹出的图形界面中配置： Application Path: D:\Redis\redis-server.exe Arguments: D:\Redis\redis.windows.conf然后： nssm start RedisNSSM 还支持标准输出/错误重定向到日志文件，适合需要记录 Redis 日志的场景。