返回市场
核心-MCP

核心-MCP

作者:KunihiroS7 星标更新:2025-05-16

项目介绍

CoRT MCP Server

smithery 徽章

这是一个递归思维链(CORT)MCP服务器。 原始项目如下,我非常感谢原作者的工作。

原始:PhialsBasement/Chain-of-Recursive-Thoughts: 我通过让AI反复与自己辩论来让它更深入地思考。效果非常好。 https://github.com/PhialsBasement/Chain-of-Recursive-Thoughts

发布说明

0.2.0 更新了LLM列表 0.1.0 初始发布

特性

  • 通过MCP服务器提供CoRT方法,使AI反复与自己辩论以进行更深入的思考。效果非常好。

工作检查

Roo代码 / Cline

MCP主机配置

建议超时时间为300秒。(有时可能需要比预期更长的时间) 需要OPENROUTER_API_KEY。https://openrouter.ai/

示例:禁用日志

"CoRT-chain-of-recursive-thinking": {
  "command": "pipx",
  "args": ["run", "cort-mcp", "--log=off"],
  "env": {
    "OPENAI_API_KEY": "{apikey}",
    "OPENROUTER_API_KEY": "{apikey}"
  }
}

示例:启用日志(需要绝对的日志文件路径)

"CoRT-chain-of-recursive-thinking": {
  "command": "pipx",
  "args": ["run", "cort-mcp", "--log=on", "--logfile=/workspace/logs/cort-mcp.log"],
  "env": {
    "OPENAI_API_KEY": "{apikey}",
    "OPENROUTER_API_KEY": "{apikey}"
  }
}
  • --log=off : 禁用所有日志(不写入任何日志)
  • --log=on --logfile=/absolute/path/to/logfile.log : 启用日志并写入指定的绝对文件路径
  • 当启用日志时,这两个参数是必需的。如果缺少任何一个参数,路径不是绝对路径,或给定值无效,服务器将以错误退出。

注意:

  • 当启用日志时,日志仅写入到指定的绝对文件路径。相对路径或省略--logfile会导致错误。
  • 当禁用日志时,不会输出任何日志。
  • 如果缺少或提供了无效的必要参数,服务器将无法启动,并会打印错误消息。
  • 日志文件必须可由MCP服务器进程访问和写入。
  • 如果您遇到运行此服务器的问题,可能是由于缓存了旧版本的cort-mcp。请尝试使用最新版本(将x.y.z设置为最新版本)的cort-mcp运行它,如下设置:
"CoRT-chain-of-recursive-thinking": {
  "command": "pipx",
  "args": ["run", "cort-mcp==x.y.z", "--log=off"],
  "env": {
    "OPENAI_API_KEY": "{apikey}",
    "OPENROUTER_API_KEY": "{apikey}"
  }
}

可用工具

  • {toolname}.simple 无详细信息,仅输出最终选定的替代方案。
  • {toolname}.details 包含LLM响应历史的详细信息。
  • {toolname}.mixed.llm 多LLM推理。
  • {toolname}.neweval 新的评估提示。

请参阅以下详细信息。

CoRT是什么?

flowchart TB
    Start[用户查询] --> DetermineRounds[AI确定思考轮数]
    DetermineRounds -->|确定思考轮数 1-5 轮| InitialResponse[初始响应\ntemperature=0.7]

    InitialResponse --> Round1[开始第1轮]

    subgraph "第1轮"
        Round1 --> R1A1[创建替代方案1 temperature=0.7]
        Round1 --> R1A2[创建替代方案2 temperature=0.8]
        Round1 --> R1A3[创建替代方案3 temperature=0.9]

        InitialResponse & R1A1 & R1A2 & R1A3 --> R1Eval[评估 temperature=0.2]
        R1Eval --> R1Best[第1轮最佳响应]
    end

    R1Best --> Round2[开始第2轮]

    subgraph "第2轮"
        Round2 --> R2A1[创建替代方案1 temperature=0.7]
        Round2 --> R2A2[创建替代方案2 temperature=0.8]
        Round2 --> R2A3[创建替代方案3 temperature=0.9]

        R1Best & R2A1 & R2A2 & R2A3 --> R2Eval[评估 temperature=0.2]
        R2Eval --> R2Best[第2轮最佳响应]
    end

    R2Best --> Remaining[剩余轮次 重复相同过程]
    Remaining --> FinalBest[最终轮次最佳响应]

    FinalBest --> FinalResponse[最终响应]

主要增强功能

从原始CoRT方法论中进行了几项增强。

  1. 多LLM推理:每个替代方案都随机生成不同的LLM(模型+提供商)。
  2. 评估增强:通过添加一个要求AI解释其推理的提示来更新评估提示。(原始提示可通过工具获取)

多LLM推理

概述: 这是一个新工具,它在传统的CoRT思考流程中增加了“随机选择不同LLM(模型+提供商)用于每个替代方案”的探索策略。 这允许最大限度地利用异构模型的知识和想法,并从更广泛的选项中选择最优解决方案。

  • 该功能可通过混合LLM工具获得。

LLM列表

  • 选择了较轻且较快的模型以提高用户体验。
MIXED_LLM_LIST = [
    {"provider": "openai", "model": "gpt-4.1-nano"},
    {"provider": "openrouter", "model": "meta-llama/llama-4-scout:free"},
    {"provider": "openrouter", "model": "google/gemini-2.0-flash-exp:free"},
    {"provider": "openrouter", "model": "mistralai/mistral-small-3.1-24b-instruct:free"},
    {"provider": "openrouter", "model": "meta-llama/llama-3.2-3b-instruct:free"},
    {"provider": "openrouter", "model": "thudm/glm-4-9b:free"},
]

混合LLMs工具流程。

  • 对于每个替代方案,从上述列表中随机选择一个LLM(模型+提供商)
  • 总是在日志中记录“每个生成的替代方案所使用的模型和提供商”
  • 在详细模式下,明确包含“每个替代方案所使用的模型和提供商”在响应历史信息中

评估增强

概述: 更改了评估提示,使其更加丰富。(原始提示可通过工具获取) 使用{toolname}.neweval提示,要求AI解释其推理。

原始提示

f"""原始消息:{prompt}
评估这些响应并选择最佳的一个:
当前最佳:{current_best}
备选方案:
{chr(10).join([f"{i+1}. {alt}" for i, alt in enumerate(alternatives)])}
哪个响应最能解决原始消息?考虑准确性、清晰度和完整性。
首先,仅用'current'或数字(1-{len(alternatives)})回应。
然后在新的一行中,用一句话解释你的选择。"""

增强提示

f""" 原始消息:{prompt}
您是一位专家评估员,负责选择最能满足用户真正需求的响应,考虑多个视角。
当前最佳:{current_best}
备选方案: {chr(10).join([f"{i+1}. {alt}" for i, alt in enumerate(alternatives)])}
请遵循以下评估过程:
意图分析:用户真正寻求的是什么?除了表面问题外,可能存在哪些潜在需求?
情境考量:这个问题可能源于哪些可能的情况或背景?
多样性评估:响应是否考虑了不同的观点或可能的解释?
实用性评估:响应在用户的实际环境中有多有用?
一致性检查:响应内部是否一致且逻辑连贯?
对于每个响应(包括当前最佳):
它是否解决了用户的真实问题?
它是否平衡了准确性和实用性?
它是否避免了不必要的假设或偏见?
它是否足够灵活以适用于各种上下文或情况?
它是否考虑了例外或特殊情况?
完成您的评估后:
仅用'current'或数字(1-{len(alternatives)})表示您的选择。
在下一行中,具体解释为什么这个响应最能满足用户的真实需求。"""

参数规格和回退处理

此API根据指定的providermodel参数确定实际使用的模型,并在发生错误时进行回退处理。

  1. 提供商(provider)解析

    • 未指定时:默认使用openrouter作为提供商。
    • 指定了无效值(除openaiopenrouter以外):回退到默认提供商openrouter
  2. 模型(model)解析

    • 未指定时
      • 如果解析的提供商是openrouter:使用默认模型mistralai/mistral-small-3.1-24b-instruct:free
      • 如果解析的提供商是openai:使用默认的OpenAI模型。
    • 指定(具有有效的提供商)时
      • 使用解析提供商下的指定模型名称。
      • 重要:在此阶段,不会验证指定的模型名称是否确实存在于提供商中。
  3. API调用和错误回退

    • 首先尝试使用上述规则解析的提供商和模型组合进行API调用。
    • 如果API调用过程中发生错误(例如,指定的模型不存在于提供商中,API密钥认证错误等):
      • 条件1:首次尝试调用的提供商不是openai
      • 条件2:系统中设置了环境变量OPENAI_API_KEY
      • 如果满足以上两个条件,则系统自动重试使用openai提供商的默认模型的过程(这是回退处理)。
      • 如果上述任一或两个条件不满足(例如,首次尝试是openai,或未设置OPENAI_API_KEY),则返回初始错误作为最终结果,这种类型的回退不会发生。

关于环境变量的注意事项:

  • 使用openrouter需要OPENROUTER_API_KEY
  • 使用openai或利用上述回退功能需要OPENAI_API_KEY
  • 如果没有设置相应的API密钥,API调用将会失败(根据回退条件,回退到OpenAI也会失败)。

许可证

MIT

随心所欲地使用