Skip to main content

Search: #效率工具

面条的草稿箱
面条的草稿箱
无原创，纯转发

  1. Slim Tools：为 AI 智能体减负的统一 MCP 工具网关

    在使用 AI Agent（如 Claude、Cursor 等）时，你是否遇到过因为加载了太多 MCP 或 OpenAPI 工具，导致上下文窗口（Context Window）被严重占用、Token 消耗飞涨的情况？

    Slim Tools 提供了一个巧妙的解决方案：它将所有上游工具统一封装进一个极简的 MCP 接口中。

    核心特性：

    • 统一入口：无需向 AI 暴露所有工具，只需提供一个 Slim Tools 的 MCP URL（https://slim.tools/mcp）。
    • 按需探索：AI 代理在运行阶段仅能看到 discover_tools（工具搜索）和 execute_code（沙盒代码执行）两个核心能力。
    • 高效联动：AI 通过搜索找到匹配的工具，然后在沙盒中运行代码来组合并调用这些上游 API（如 GitHub、Notion、Slack、Figma 等）。
    • 简化授权：统一管理所有上游服务的 OAuth 授权，无需重复配置。

    通过这种“运行时发现”的设计，AI 代理无需在上下文里“背负”沉重的工具集，不仅让 Prompt 更加清爽，也让 Agent 的响应速度大幅提升。

    原文链接：http://slim.tools

    #AIAgents #MCP #开发者工具 #效率工具
    Slim Tools
    Slim Tools | Tool Orchestration Runtime for AI Agents
    Slim Tools | Tool Orchestration Runtime for AI Agents
    Move MCP and OpenAPI tool orchestration out of model context and into one sandboxed runtime.

  2. 以“推理速度”交付：AI 编程把瓶颈从写代码变成了等模型

    这篇文章的核心观点很直接：AI 编程代理的能力跃迁后，作者交付软件的速度越来越不取决于“敲代码”，而更受限于两件事——模型推理时间（inference time）和少数真正需要深度思考的设计决策。

    作者回顾了今年的变化：从最初“有些提示能一次跑通就很惊喜”，到现在“默认就该一次跑通”。在这种前提下，他甚至不再逐行读代码，而是看执行/修改流，关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

    文章也给了不少可复用的工作方法：

    • 先从 CLI 做起：任何产品先做命令行版本，方便代理直接运行验证，形成闭环；核心逻辑稳了再上 UI（比如扩展、App）。
    • 关键决策是生态与依赖：语言/框架/依赖选对了，代理更容易一次完成；作者常用 TypeScript（Web）、Go（CLI）、Swift（macOS/iOS）。
    • 更偏向“对话式协作”，而不是复杂流程：先和模型聊清楚、让它探索代码、共创方案，满意后再让它开干；他认为“Plan mode”更像旧时代不得已的手段。
    • 对比 codex 与 Opus：codex 常会先长时间读代码再动手，虽然更慢但更稳，尤其适合大型功能和重构；Opus 更“急”，适合小改动但更容易漏上下文。
    • 迭代式构建，不依赖回滚：不喜欢 checkpoint/频繁 revert，更多是让模型继续改、继续朝更好的方向“绕山而上”。
    • 自动化与多项目并行：同时推进多个项目，用队列把想法排进去；瓶颈往往是人而不是编排系统。
    • 配置思路：提高工具输出 token 上限、合理设置自动压缩阈值，让模型能一次读更多文件；作者强调新压缩机制更可靠，甚至像一次“复查”。

    如果用一句话总结：当“写代码”越来越像可并行外包给代理的体力活，工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上；而真正影响交付速度的，往往是推理等待时间和你是否想清楚要做什么。

    原链接：https://steipete.me/posts/2025/shipping-at-inference-speed
    #AI编程 #Codex #开发工作流 #效率工具 #软件工程
    steipete.me
    Shipping at Inference-Speed | Peter Steinberger
    Shipping at Inference-Speed | Peter Steinberger
    Why I stopped reading code and started watching it stream by.

  3. 一份配置，多端通用：MCP Config 转换器

    mcp-config 是一个参考实现：把“同一份 MCP Server 配置”一键转换成不同应用所需的配置文件或命令，避免在 Claude Desktop、Cursor、VS Code 等多处重复手工改配置。

    它解决什么问题

    • 只维护一份 MCP Server 定义（支持远程 HTTP / 本地 stdio）
    • 按目标客户端输出对应格式：JSON / CLI / TOML
    • 适配 30+ 客户端格式，减少迁移与同步成本

    怎么用（概念流程）

    • 将仓库的 src/ 复制到你的项目中
    • 使用 getClients() 查看支持的客户端
    • 用 transformConfig({ server, client }) 生成目标客户端需要的配置字符串（例如 Cursor 的 JSON，或 Claude Code 的添加命令）

    支持范围（示例）

    • JSON 类：Claude Desktop、Cursor、Windsurf、VS Code/Copilot、JetBrains、Zed、Warp、Perplexity Desktop 等
    • CLI 类：Claude Code、Amp、OpenAI Codex CLI 等

    适合谁

    • 同时在多个 IDE/客户端里用 MCP 的开发者与团队
    • 想把“配置维护”从手工劳动变成可复用工具链的人

    原链接：https://github.com/iannuttall/mcp-config

    #MCP #配置管理 #开发工具 #TypeScript #效率提升
    GitHub
    GitHub - iannuttall/mcp-config: Turn one MCP server setup into the right format for lots of apps.
    GitHub - iannuttall/mcp-config: Turn one MCP server setup into the right format for lots of apps.
    Turn one MCP server setup into the right format for lots of apps. - iannuttall/mcp-config
1px