Project
多站点 API 逆向与 MCP Server 工程
从浏览器网络请求出发识别稳定接口，再把分散的站点能力封装成可验证、可恢复的 MCP 工具链。
Python · MCP · Playwright · Pydantic · API Reverse Engineering · Git
Product Snapshot
- Role
- 工程实习生 / 独立贡献者
- Users
- 需要把多个外部站点接入 Agent 工作流的工程团队。
- Stage
- 2026.01-2026.02 完成接口发现、字段文档、MCP 封装、启动测试和验证报告。
- Focus
- Network-first API discovery、Pydantic 数据模型、MCP 工具设计与长任务恢复。
- Validation
- 形成 14 组站点能力；一次集中提交涉及 231 个文件、约 2.05 万行新增代码。
- Public Proof
- 代码记录、接口文档、启动测试和验证报告交叉印证；公开叙述已去除内部站点与凭据细节。
Next Step
问题
当 Agent 需要操作多个站点时，直接依赖页面点击通常不够稳定：页面结构会变，字段含义不统一，长任务也容易在中途失败。这个项目的目标，是先找到站点背后更稳定的请求接口，再把它们变成有明确输入输出约束的 MCP 工具。
我的工作
我采用 network-first 的方法，从浏览器请求链路中定位接口，整理参数、返回字段与错误条件；随后用 Python 和 Pydantic 建模，并基于统一的 MCP 核心层封装能力。
工程链路还包括启动检查、字段验证、重试、检查点恢复和结果报告。这样一来，工具不仅“能调用”，也能在失败后说明发生了什么，并从可控位置继续。
结果与证据
最终实现覆盖 14 组站点能力。代码审计记录显示，一次集中提交涉及 231 个文件和约 2.05 万行新增代码。这个页面只公开工程方法和汇总规模，不披露内部站点、接口地址、凭据或提交标识。
我带走的经验
浏览器自动化并不只是“让模型点按钮”。更可靠的系统需要把页面探索、接口理解、类型约束、恢复机制和评测证据放在同一条工程链路里。
配置公开站点的 Giscus 环境变量后，这里就会出现讨论区。