Hacker News 中文摘要

RSS订阅

工具：代码即一切 -- Tools: Code Is All You Need

原文链接 | HN讨论 | 2025-07-04 03:14:36

文章摘要

作者对MCP（模型上下文协议）持保留态度，认为其存在两大缺陷：缺乏真正的可组合性，且需要过多的上下文信息。通过实验比较，作者发现使用gh CLI工具比GitHub MCP更高效。尽管MCP在特定领域（如金融公司的自动化任务）可能有潜力，但作者认为其在一般代码生成中的应用并不理想，因为现有模型在这方面已经表现很好。

文章总结

文章总结

标题: 工具：代码就是一切
发布时间: 2025年7月3日
来源: https://lucumr.pocoo.org/2025/7/3/tools/

主要内容

  1. 对MCP（模型上下文协议）的批评
    作者对MCP持保留态度，认为其存在两大问题：

    • 不可组合性：大多数组合通过推理完成，缺乏真正的可组合性。
    • 上下文需求过高：每次调用工具都需要大量上下文，远不如直接编写和运行代码高效。

  2. MCP的未来
    尽管MCP在某些领域（如金融公司的特定任务自动化）可能有其价值，但作者认为在当前形式下，MCP的使用难度高于直接编写代码，尤其是在依赖推理的情况下。现有的工具扩展方案大多依赖于LLM（大语言模型）进行过滤，尚未有更好的替代方案。

  3. 用代码替代自己
    作者提出，解决自动化问题的核心是代码。即使是非程序员，也可以通过LLM生成代码来自动化任务。然而，LLM的使用面临成本、速度和可靠性等问题，这些问题在考虑工具使用或MCP之前必须解决。

  4. 大规模自动化
    自动化的关键在于重复性任务。对于这些任务，使用代码比依赖推理更为可靠。通过生成代码，可以更好地验证和验证过程，而不是依赖LLM的推理。

  5. LLM生成代码的实例
    作者分享了自己将博客从reStructuredText转换为Markdown的经历。通过让LLM生成代码，作者能够信任这一过程，并通过另一个LLM验证代码的正确性。这种方法不仅提高了效率，还减少了数据丢失的风险。

  6. MCP的局限性
    作者指出，MCP在处理复杂任务时难以消除推理的需求。相比之下，生成代码的方法更为高效和可靠，尤其是在已知任务的情况下。

  7. 未来的方向
    作者认为，MCP在当前形式下难以扩展，特别是在大规模自动化方面。未来可能需要寻找更好的抽象方式，结合MCP和代码生成的优势，构建更好的沙箱和API，以支持更高效的自动化流程。

  8. 鼓励探索
    作者鼓励人们绕过MCP，探索LLM在代码生成方面的潜力。通过赋予LLM编写代码的能力，可以实现更多的自动化任务。

进一步阅读

这篇文章深入探讨了MCP的局限性，并提出了通过代码生成实现自动化的优势，为未来的自动化工具开发提供了新的思路。

评论总结

评论主要围绕LLM（大语言模型）与MCP（多组件管道）工具的使用展开，观点多样且涉及多个方面。以下是主要观点和论据的总结：

1. LLM与MCP工具的对比

  • 支持LLM的观点：LLM在生成代码和使用CLI工具时效率更高，尤其是在处理常见任务时表现优异。例如，mritchie712提到使用gh CLI工具比MCP更高效，且LLM能够通过上下文快速完成任务。
    • 引用：“try completing a GitHub task with the GitHub MCP, then repeat it with the gh CLI tool. You'll almost certainly find the latter uses context far more efficiently and you get to your intended results quicker.”
  • 支持MCP的观点：MCP在处理内部工具或文档较少的API时更具优势，因为它能够提供可靠的输入输出，减少LLM生成代码的错误。victorbjorklund指出，MCP在处理复杂或不熟悉的系统时更为可靠。
    • 引用：“With MCP, if the tools are properly designed and receive correct inputs, they work reliably.”

2. LLM的局限性

  • LLM的可靠性问题：LLM生成的代码可能不够精确，尤其是在处理复杂任务时，容易陷入局部最优解。antirez认为，目前LLM在处理编程任务时仍需要人类的参与，以确保代码的质量。
    • 引用：“LLMs are great at certain tasks but they often get trapped into local minima.”
  • 成本与速度：LLM的使用成本虽然逐渐降低，但在处理大规模任务时，速度和可靠性仍是一个问题。JyB提到，LLM的成本和速度在不断改进，但可靠性仍与提示词的质量相关。
    • 引用：“cost: They keep getting cheaper and cheaper. It's ridiculously inexpensive for what those tools provide.”

3. 工具与代码生成的平衡

  • 工具与代码生成的对比：工具提供了约束和节省了token，而代码生成则提供了灵活性。elyase指出，生成代码在某些情况下可能更优，尤其是随着LLM的改进。
    • 引用：“tools offer constraints and save tokens, code gives you flexibility.”
  • 工具与代码的结合：tristanz提到，可以将MCP工具与LLM生成的代码结合使用，以处理复杂的任务，并通过持续学习优化工作流程。
    • 引用：“We inject MCP tools into a sandboxed code interpreter and have the agent generate both direct MCP tool calls and composable scripts.”

4. 对MCP的批评

  • MCP的复杂性：MCP的复杂性可能不必要，尤其是当LLM可以直接生成代码时。pamelafox指出，MCP在处理某些任务时可能效率低下，直接使用API调用更为高效。
    • 引用：“MCP servers might be fun to get an idea for what's possible, and good for one-off mashups, but API calls are generally more efficient and stable.”
  • MCP的命名问题：graerg对MCP的缩写表示不满，认为这种缩写过于复杂。
    • 引用：“Oh god please no, we must stop this initialism. We've gone too far.”

5. 未来展望

  • LLM与工具的融合：jumploops认为，未来LLM与工具的使用将逐渐融合，工具的预训练集将成为LLM的主要依赖。
    • 引用：“At some point this will start to converge, or at least appear to do so, as the majority of tools a model needs will be in its pre-training set.”
  • LLM的潜在应用：luckystarr提到，LLM可以自动生成代码片段之间的适配器，但这一过程成本较高，未来可能需要更高效的系统。
    • 引用：“While LLMs could generate those adapters between distinct pieces automatically, it's a expensive (latency, tokens) process.”

总结：

评论中对LLM和MCP的使用各持己见，LLM在生成代码和快速处理任务方面表现出色，但在复杂任务中仍需要人类的参与和工具的辅助。MCP在处理内部工具和复杂系统时更为可靠，但其复杂性和效率问题也受到批评。未来，LLM与工具的融合可能会带来更高效的工作流程。