最近，在Hacker News上刷到一个叫 PatchworkMCP 的项目，作者说他"build MCP servers for a living"，然后抛出一个问题：我们怎么知道AI agent在使用我们的server时遇到了什么问题？

我愣了一下。对啊，我们平时开发MCP server，工具列表是自己设计的。但agent真正需要什么，其实我们是在猜的。

那个让我停下来的例子

PatchworkMCP的作者举了个例子。他把这个反馈系统集成到一个AI成本管理的MCP server里，然后Claude在一次对话中上报了这样一个问题：

“需要一个search_costs_by_context工具，可以接受context的key-value对进行AND逻辑过滤，结合标准的时间/服务/客户过滤器，返回分页的事件记录。”

这不是模糊的抱怨。这是一个完整的工具规格说明书。

我当时就想，这太合理了。agent在试图完成任务的时候，它自己知道缺什么。我们只是没给它一个上报的渠道。

我决定动手试一试

当然，我直接去看了一下PatchworkMCP的代码… 好吧，功能挺完整的，有dashboard、有自动PR生成、有GitHub集成。但对于想验证这个想法的我来说，有点重。

所以我决定自己做一个简化版。核心目标只有一个：验证"agent上报 → 开发者查看 → 理解问题"这个链路能不能跑通。

第一步：设计反馈的数据结构

最开始的版本我想得很简单：让agent发个HTTP POST，说"我需要某某功能"就行了。

但写了几行代码之后发现不行。这种自由文本的反馈，每台agent说得都不一样。有的写一句话，有的写一大段，根本没法结构化处理。

后来看了PatchworkMCP的设计，学到了。他们定义了一套schema：

  • what_i_needed - 需要的能力（必须）
  • what_i_tried - 尝试了哪些工具（必须）
  • gap_type - 缺口类型：missing_tool / incomplete_results / missing_parameter / wrong_format / other
  • suggestion - agent建议的修复方案
  • user_goal - 用户原本想做什么
  • resolution - 最终结果：blocked / worked_around / partial

这个设计很妙。它既给了agent表达的框架，又保留了灵活性。我直接借用了这个思路。

遇到的第一个坑：同步阻塞

一开始我用的是requests库做HTTP POST：

def report_gap(what_needed, what_tried):
    requests.post("http://localhost:8099/feedback", json={...})
    return "Feedback sent"

问题来了。如果sidecar没启动，或者网络卡了，这个调用会一直阻塞，MCP server就卡住了。

解决起来倒是不难，改成异步就行：

async def _send_feedback(feedback: dict):
    async with httpx.AsyncClient() as client:
        await client.post(f"{SIDECAR_URL}/api/feedback", json=feedback)

# 在tool里不等待，直接丢到后台
asyncio.create_task(_send_feedback(feedback))

但这个小坑让我意识到：MCP tool的实现要考虑不能阻塞主流程。反馈上报应该是"尽力而为"，而不是"必须成功"。

第二个坑：agent不会主动用

这是我没想到的。我把report_tool_gap工具写好了，描述也写了，但agent在遇到问题时并不会自动调用它。

除非——你在描述里明确告诉它：“Call this when you can’t complete a task because of missing functionality…”

这让我重新思考tool description的写法。它不只是一个技术文档，更像是给agent的指令。你需要明确地告诉它在什么场景下应该使用这个工具。

第三步：写个能看的Dashboard

Feedback要能查看才有价值。我本来想用React写个漂亮的dashboard，但后来觉得… 等等，我是在验证想法，不是在造产品。

所以最后写了个纯HTML+JS的版本，内嵌在Python代码里。虽然丑，但能跑。

DASHBOARD_HTML = """
<!DOCTYPE html>
<html>
<head>
    <title>MCP Feedback Dashboard</title>
    <style>
        body { background: #0d1117; color: #c9d1d9; ... }
        ...
    </style>
</head>
<body>
    <h1>🧩 MCP Feedback Dashboard</h1>
    <div id="feedback-list"></div>
    <script>
        // 每5秒轮询刷新
        setInterval(loadFeedback, 5000);
    </script>
</body>
</html>
"""

暗色主题是因为… 好吧，程序员都喜欢暗色主题。

第四步：设计"不完整"的示例server

为了演示反馈功能，我特意设计了一个有缺陷的TODO server：

@mcp.tool()
def list_todos() -> list:
    """列出所有待办事项（没有过滤功能——这是个故意的缺口）"""
    return todos

@mcp.tool()
def mark_done(todo_id: int) -> dict:
    """标记待办完成（没有批量操作——也是个缺口）"""
    ...

注释里故意写上了"这是个缺口"，既是给agent看的提示，也是给自己留的备注。

然后我在server启动时打印了这样一段说明：

这个server故意设计了一些缺口，用来演示反馈功能：
- ❌ 没有按状态过滤todo
- ❌ 没有批量标记完成  
- ❌ 没有删除todo功能
- ❌ 没有搜索/过滤功能

当agent遇到这些问题时，可以调用 report_tool_gap 工具上报。

跑起来的样子

启动之后，打开 http://localhost:8099 能看到dashboard。它长这样（想象一个暗色主题的简单列表）：
在这里插入图片描述

每个反馈卡片显示：

  • server名称
  • 缺口类型（用不同颜色标签）
  • agent需要什么
  • 它尝试过什么
  • 它的建议

说实话，看到这个界面跑起来的时候，我有点兴奋。这就是我想象中的样子——agent在说话，开发者在听。

我被什么限制了

这个实验版本离PatchworkMCP的完整实现还差很远：

  1. 没有反馈聚类 - 同样的问题会被多次报告，没有合并机制
  2. 没有自动PR生成 - 这是原版最酷的功能，但实现复杂
  3. 只支持Python - 原版有Python/TypeScript/Go/Rust的drop-in
  4. 没有和GitHub集成 - 原版能直接创建draft PR

但这些限制是故意的。我的目标是验证核心想法，而不是复制一个完整产品。

一点想法

做这个小项目让我对MCP生态有了更深的理解。

Gergely Orosz在他的newsletter里提到，MCP生态有个"builder多于user"的问题。开发者发布了server，但不知道agent实际需要什么。

PatchworkMCP的思路是解决这个问题的关键：让agent告诉你。这不是什么复杂的技术创新，而是一个思维转变——把agent从"被动的工具使用者"变成"主动的反馈提供者"。

我写这个简化版的过程中，最大的收获不是代码，而是对MCP设计哲学的理解。好的协议不只是连接，还要让连接的双方能够相互理解、相互改进。

试试这个项目

如果你也想试试：

git clone https://github.com/YaBoom/mcp-feedback-loop-zyt.git
cd mcp-feedback-loop-zyt
pip install -r requirements.txt
./start_demo.sh

然后配置Claude Desktop使用example_server/simple_server.py作为MCP server。当你让Claude做一些它做不到的事情时（比如"删除所有已完成的todo"），它会调用report_tool_gap工具上报。

打开 http://localhost:8099 就能看到它的反馈。

说实话，这只是个初步探索。还有很多问题没解决：

  • 怎么处理大量重复的反馈？
  • 如何让agent更智能地判断什么时候该上报？
  • 反馈驱动的开发流程应该是什么样的？

你有没有在开发MCP server时遇到过"不知道agent需要什么"的问题？你是怎么解决的？

⚠️ 声明：这只是实验代码，用于学习PatchworkMCP的思路。生产环境请使用原版：keyton-weissinger/patchworkmcp

相关链接

  • 📁 本项目：https://github.com/YaBoom/mcp-feedback-loop-zyt
  • 🔗 PatchworkMCP原版：https://github.com/keyton-weissinger/patchworkmcp
  • 📖 MCP官方文档：https://modelcontextprotocol.io/
  • 📰 Gergely Orosz的MCP深度分析：https://newsletter.pragmaticengineer.com/p/mcp-deepdive
# 人工智能 # python
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

训练数据选择又有新方法了？——两篇文章的阅读笔记 Less is Enough和 OPUS

avatar 2048 AI社区

新商家值不值得开诚信通？ROI算给你看

有意思的是，自2024年10月“诚信通AI版”上线以来，新入驻商家在买家数、询盘量、交易额及复购率等关键指标上，普遍实现了两位数以上的同比增长——买家数增幅甚至超过20%。接下来，集中火力打“潜力品”。务必开启“客户增长任务”和“AI经营分析”——前者帮你自动唤醒沉睡客户、促进复购，后者则像一个24小时在线的运营顾问，告诉你哪里该优化、哪里有机会。截至2025年2月，1688平台年度活跃买家其中B

avatar 2048 AI社区

Ubuntu系统网络连接模式实测

备注：主机通过wifi联网，主机A和主机B通过网线组成局域网，且A和B设备是可以互通的。结果：同设备主机与虚拟机A1和A2能互通，不同设备A1/A2和B也可以互通，上不了网（ping www.baidu.com 失败）。结果：同设备主机与虚拟机A1和A2不能互通，不同设备A2和B也互通不了，上不了网（ping www.baidu.com 失败）。结果：同设备主机与虚拟机A1和A2不能互通，不同设备

avatar 2048 AI社区