在开发用于观测工具的MCP（多云程序）服务器过程中，作者遇到了几个技术挑战和重要教训，通过不断改进最终达成了较好的成果。MCP服务器旨在为AI代理提供动态代码分析能力，以提升产品的价值。以下是一些主要的教训： 教训一：避免一次性传输大量数据 最初的原型证明了MCP的巨大潜力，但作者很快发现直接将现有的详细API暴露给AI代理并不是最佳选择。这些API返回的数据量庞大，导致在测试环境中的查询响应就达到了约360k字符和16k单词，远超模型的处理能力限值。使用的是Claude 3.7 Sonnet模型，其理论支持上限为200k token，而实际操作中却显得力不从心。后来，作者转而使用Gemini 2.5 Pro模型，其支持高达一百万token，确实得到了更智能的响应。但为了确保系统在不同条件下都能可靠运行，作者最终优化了API结构，使其能够逐步、有序地返回重要新异常并提出修复建议，而不是一次性传输全部数据。 教训二：关注实际日期和时间 作者观察到，当从特定时间范围获取错误数据时，AI代理倾向于使用ISO 8601时间持续格式而非具体的时间戳。原因是代理可能不知道当前的具体时间。因此，使用时间持续格式成为了一个很好的解决方案。不过，作者建议在工具参数描述中明确这一点，提供具体的示例，以便用户更好地理解如何使用。 教训三：教育代理正确的做法 早期实现在代理使用某些功能时会出现错误，例如，根据提示中提供的环境名称直接调用API，导致无法获取有效数据。为了改善这一点，作者修改了API的返回逻辑，在代理提供错误参数时返回详细的错误说明，甚至提供可用的环境ID列表。这些改进使代理能够从错误中学习，提高未来使用的准确性。 教训四：强调用户意图而非功能 在文档编写方面，作者最初只是简单描述了每个工具的功能，如一个工具可以显示代码在运行时是如何被使用的。然而，这样做并没有让代理充分理解这些工具在何种情况下最适用。后来，作者重新撰写文档，详细列出了这些工具在实际中的应用场景，如检测潜在的破坏性变更、生成基于运行时使用的测试等。通过这种方式，代理能够更好地识别用户的意图，从而更精准地调用相应的工具。 教训五：记录JSON响应 由于JSON标准不支持注释，代理在解读返回数据时可能会缺乏上下文。为了解决这个问题，作者在JSON响应的开头添加了一个“_comment”元素，详细解释了每个字段的意义。以一个错误得分对象为例，注释清楚地列出了各个得分参数的含义及其对总体得分的影响。这样不仅提高了代理的理解能力，也让用户在询问时更容易获得清晰的解答。 架构选择：SSE与STDIO 在开发MCP服务器时，可以选择两种架构：一种是常见的客户端命令行触发式（通过CLI），另一种是服务端事件流（SSE）。作者选择了SSE架构，因为它减少了在客户端机器上运行CLI命令的摩擦，同时允许作者随着应用的更新同步维护MCP服务器代码。这一选择还解决了版本兼容性的问题。虽然目前不是所有客户端都支持SSE模式，但可以通过supergateway这样的桥梁工具作为代理，实现SSE服务器的功能。 业内人士评价 专家认为，作者的经验和教训对于MCP开发者具有重要的指导意义。尽管MCP技术还处于起步阶段，但通过不断的实践和总结，社区将会逐渐形成更多最佳实践。Digma作为一家专注于代码可观测性和自动化修复的公司，其在MCP领域的探索为业界提供了宝贵的参考。