工具层正在重复造轮子

Agent 真正进入工作流后，工具接口会迅速膨胀。一个内部系统原本有 HTTP API、后台任务和 Web 控制台，现在还要暴露给 Claude、Cursor 或其他 runtime 作为 MCP tool。

最常见的做法是再包一层：原来有 FastAPI endpoint，现在写一个 FastMCP 注册；原来有 JSON schema，现在为 Agent 再写一份；原来有流式返回，现在另写一套路由。这在十个工具时还能忍，在上百个工具时会变成维护灾难。

HarnessAPI 抓住的重点是接口双写带来的漂移。业务逻辑变了，HTTP 端更新了，MCP 端忘了改；schema 一边严格，一边宽松；错误处理和鉴权也慢慢不一致。

它的单一真源设计

论文提出把 typed skill folder 作为单一真源。一个 handler.py 加 Pydantic schema，自动派生流式 HTTP endpoint、OpenAPI/Swagger UI 和 MCP tool，并且可以在同一个进程里服务。

这套设计保留 FastAPI 生态，包括 middleware、dependency injection 和部署方式，同时用动态代码生成处理 FastMCP 检查类型注解时遇到的限制。论文还支持双模式 content negotiation，让同一个 handler 同时服务 SSE streaming 和 JSON client。

论文报告，在六个代表性 skill 上，HarnessAPI 相比手工维护 FastAPI server 加 FastMCP server 的双栈，减少 74% framework-facing boilerplate。这个数字不是最终答案，但足以说明重复层很厚。

对 Agent 平台的意义

Agent 工具生态很容易走向混乱：每个产品都发明一套 tool wrapper，每个团队都写自己的 schema 转换，每个 runtime 都要求不同包装。HarnessAPI 的价值，是把工具层重新拉回工程常识：业务逻辑应该只有一个真源。

这对企业尤其重要。企业内部工具不是玩具 API，里面有权限、审计、限流、错误码、版本兼容和回滚要求。如果 MCP tool 和正式 API 分叉，Agent 用到的可能是一套更脆、更少审计的影子接口。

更合理的方向是：工具从设计时就同时面向人、服务和 Agent。MCP 是一个暴露面，不是另一份业务逻辑。

这类框架的限制

HarnessAPI 解决的是接口包装和 schema 漂移，不会自动解决权限、数据分级和工具滥用。一个工具能被 MCP 调用，并不意味着它就适合交给 Agent 自主调用。

另外，框架采用 Python、FastAPI 和 Pydantic 路线，对已有 Java、Go、Node 内部服务体系的团队未必能直接迁移。它更像一个设计样板：从单一 skill 源码生成多种接口，而不是所有团队都必须用同一个库。

对国内团队来说，最值得带走的重点是原则：不要把 Agent 工具层做成旁路系统。旁路越多，安全和维护越难。