Ghost Agent（Coreon MCP 执行引擎）
把 AI 规划与工具执行解耦的 MCP 执行引擎：自然语言进，结构化工具链结果出，可在 CLI、API 与 Telegram 三种模式下运行。
- Star 数
- ★ 747
- 最近更新
- 29 天前
- License
- MIT
- 主语言
- Shell
- FA 评分
- 0/100 · 已阻断
30 秒速览
- 可在哪里用
- 兼容但需适配OpenAI APIClaude Code（部分支持）
- 开始前需要
- 典型场景
- Web3 开发者需要通过命令行用自然语言查询 Solana 余额、代币元数据和 DeFi 数据
- 主要局限
- 强制依赖 OpenAI API（需自备 OPENAI_API_KEY），未提供其他 LLM 提供商适配
- 源码审查
- 0/100 · 已阻断 8 项安全控制未见
这个 Agent 能做什么，适合哪些场景？
Ghost-Agent 仓库的核心产品是 Coreon-MCP-Execution-Engine，一个为结构化 ToolCall 链提供统一运行时的执行引擎。它由四大模块组成：Planner 通过 LLM 意图识别把自然语言转成 JSON 执行计划，Executor 按依赖顺序执行工具并处理重试与日志，Tool Registry 集中声明工具的名称、模块、函数签名和参数模式，Connectors 提供 CLI、API 服务器和 Telegram Bot 三种入口。引擎通过 Docker 镜像分发，无需本地依赖，仅需配置 MCP_LANG 和 OPENAI_API_KEY 即可启动。内置工具涵盖 DexScreener、Binance 行情、CryptoPanic 新闻、社交指标和链上 API，并明确以 Solana 生态为集成重点，定位为 Web3 的 AI 执行层。README 还列出了 Solana 上的 MCP 支付信号协议集成路线，自动代理支付仍在开发中。
接收来自 CLI、Telegram 或 HTTP API 的自然语言输入；Planner 基于 LLM 意图识别生成 JSON 格式的 ToolCall 链；Executor 逐步或并行执行工具，处理重试、错误恢复与日志；Tool Registry 声明每个工具的 name、module、function 与 schema，支持热插拔；内置工具集包括行情（DexScreener/Binance）、新闻（CryptoPanic）、社交指标（Twitter/Telegram）、链上 API（代币元数据/持有人）和自定义工具；最后由 Response Formatter 输出 CLI 图表、Telegram 消息或 API JSON。Solana 侧当前支持查询余额、代币元数据、DeFi 数据和合约调用；新分支 coreon-mcp 添加了 Solana 上的支付信号检测（PaymentRequired 状态），检测到付费 API 信号时会挂起执行并提示用户付款。
- Web3 开发者需要通过命令行用自然语言查询 Solana 余额、代币元数据和 DeFi 数据
- 加密社区运营者想通过 Telegram 机器人即时获取行情与新闻而无需本地环境
- 后端工程师需要一个可 Docker 部署的执行引擎，把 LLM 规划与工具执行解耦接入现有系统
- 开发者想为加密分析工作流插入自定义工具（格式化器、指标）而不改动执行逻辑
- 研究者关注 Solana 上的 Agent 支付经济，想试用 MCP 支付信号协议分支
如何安装或部署这个 Agent？
- 环境要求：Python 3.11+ 和 Docker（从 docker.com 下载安装，运行 docker --version 验证）。2. 创建目录：mkdir mcp-execution-env && cd mcp-execution-env。3. 生成环境文件：
cat <<EOF > .env
MCP_LANG=EN
OPENAI_API_KEY=sk-xxxxxxxxxxEOF
将 sk-xxxxxxxxxx 替换为你的真实 OpenAI API Key。4. 拉取镜像：docker pull coreonmcp/coreon-mcp-execution-engine。
如何使用这个 Agent？
CLI 模式：docker run --rm -it --env-file .env coreonmcp/coreon-mcp-execution-engine start cli
API 服务器模式（端口 8080）：docker run --rm -it --env-file .env -p 8080:8080 coreonmcp/coreon-mcp-execution-engine start server
Telegram Bot 模式：docker run --rm -it --env-file .env coreonmcp/coreon-mcp-execution-engine start telegram-bot
启动后直接以自然语言下达任务，引擎会生成 ToolCall 链并依次执行，返回图表、消息或 JSON。Claude 风格的 MCP stdio 模式在 alpha 版本中提供，详见 Archon-Terminal 分支。
这个 Agent 有哪些优点和局限？
- 将规划与执行解耦的清晰四层架构（Planner/Executor/Tool Registry/Connectors），工具可热插拔
- Docker 原生交付，零本地依赖，三种运行模式（CLI/API/Telegram）开箱即用
- MCP 支付信号检测已实现：检测到付费 API 时挂起执行并通知用户，PaymentRequired 状态可管理
- 通过 Armors Labs 独立安全审计并公开审计报告（PASSED）
- 强制依赖 OpenAI API（需自备 OPENAI_API_KEY），未提供其他 LLM 提供商适配
- 自动代理支付仍为路线图功能（coming soon），支付流程需人工介入
- README 存在多处命名不一致（Ghost-Agent / Archon / Coreon MCP），且指向多个外部仓库，增加溯源成本
- Solana 集成范围以查询为主，PancakeSwap 自然语言兑换、AI 钱包助手等均在路线图中未实现
这个 Agent 与同类方案有什么区别？
README 明确将项目定位为 MCP（Model Context Protocol）执行引擎，并提到 2025-09 起 alpha 版本官方支持 Claude 风格的 MCP 协议（stdio 模式），可将其与直接在 Claude 生态内调用 MCP 工具的方式对照使用。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| Ghost Agent（Coreon MCP 执行引擎） 当前 | 0 · 已阻断 | ★ 747 | 29 天前 | Shell | OpenAI API |
| Zeroshot 工程验证循环 | 63 · 存在缺口 | ★ 1.9k | 今天 | Rust | Codex · Claude Code |
| zot 编码代理 | 59 · 缺口较多 | ★ 342 | 1 天前 | Go | OpenAI API · Claude API |
| 智坤代码 (ZhikunCode) | 56 · 缺口较多 | ★ 497 | 4 天前 | Java | OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
仓库内文件互相矛盾：README自述为'Ghost-Agent/Coreon MCP Execution Engine'，package.却是'ralph-claude-code'（作者frankbria，ISC许可证），测试引用仓库中不存在的ralph_loop.sh与lib/response_analyzer.sh，MIT LICENSE版权人'Ghost Agent'与package.的ISC冲突。这种拼接式的身份冲突构成伪造来源/测试证据的红色线风险，且引用的'Armors Labs审计通过'指向另一仓库、无法在本次源文件内证实。故信任维度全部归零并触发阻塞。
package.声明的测试入口（bats，tests/unit、tests/integration）与实际提供的bash测试脚本结构不符；测试脚本依赖不存在的源文件，可靠性与自洽性均无法成立。
README声称CLI/API/Telegram三种模式与Solana集成，但仓库中没有对应实现文件，能力边界与场景描述纯属断言，无法核对。
命名严重不稳定（Ghost-Agent / Archon / Coreon-MCP-Execution-Engine / ralph-claude-code 四个名字并存），许可证元数据自相矛盾（MIT vs ISC），版本历史与维护责任指向多个互不相关的第三方仓库。
快速启动依赖外部Docker镜像coreonmcp/coreon-mcp-execution-engine，源码本身不含可运行产物，价值与成本均无法从源文件评估，且不得基于未经核实的声明计分。
核心声明（审计通过、MCP协议支持、Solana集成）全部依赖外部链接，源文件内部零佐证；事实与推断无法分离，README中的营销性断言与实际文件内容冲突。
- 源码中未见：最小权限约束只授予完成任务所需的权限：用专用账号或只读令牌，并限定可访问的目录和仓库。
- 源码中未见：执行前用户确认开启或自行加上执行前确认；先在沙箱或测试环境跑通，确认行为后再接入真实数据。
- 源码中未见：数据流向说明运行时观察它连接了哪些外部服务（代理或防火墙日志）；弄清数据去向之前不要输入敏感数据。
- 源码中未见：敏感信息处理使用专用、低权限、可随时吊销的 API 密钥，不要复用生产凭据，也不要让密钥出现在日志里。
- 源码中未见：依赖安全审查安装前固定版本并做一次依赖扫描（如 npm audit、pip-audit）；优先放在容器里运行。
- 源码中未见：外部影响披露先弄清它会写入、发送或修改哪些外部系统，用测试账号或测试仓库验证后再接入正式环境。
- 源码中未见：回滚或恢复路径运行前先备份，或在 git 分支、快照上操作，确保改动可以撤销。
- 源码中未见：来源归属可核验从官方仓库或包源安装，核对发布者和仓库地址，避免同名仿冒包。
- 红色线警示：仓库呈现多个互不相关的项目身份（Ghost-Agent、Archon、Coreon-MCP、ralph-claude-code），疑似拼接或伪造来源，禁止在生产环境信任或部署。
- 声明的第三方安全审计（Armors Labs 'PASSED'）指向外部仓库且源内无佐证，在独立核实前应视为未验证声明。
- 安装流程完全依赖未经源码验证的外部Docker镜像，执行前无法审查其真实行为，可能携带任意代码。
- README要求明文写入OPENAI_API_KEY到.env，无任何密钥保护指引。
- 测试脚本引用不存在的源文件，声称的测试覆盖不可信。