章节 01 · 围绕运行时构建
围绕运行时构建，而非桌面端
传统的基于 VPS 的交易方式往往会让可观测性变得支离破碎，信息散落在远程桌面终端、平台日志、本地文件、脚本和各个远程会话中。排查工具总是散落在你上一次使用它们的地方。
TradingHost 采用了一种完全不同的方法。您的项目运行在托管的容器运行时中，控制面板直接为您呈现该运行时产生的输出。您可以轻松检查部署后的状态、确认进程是否正常启动，以及实时查看应用在运行期间报告的信息。
可观测性不再是您在桌面端上需要单独进行的繁琐仪式，而是直接成为了交易运行时本身的一部分。
什么是“可观测性”
在 TradingHost 上，可观测性即是指运行时的日志界面。平台会捕获运行中容器的标准输出（STDOUT）和标准错误（STDERR），并将其呈现在控制面板中。这样，您无需打开服务器会话，就能直接解答有关部署运行状态的各种疑问。
章节 02 · STDOUT 与 STDERR
来自 STDOUT 与 STDERR 的运行时日志
TradingHost 采用容器化应用的标准日志接口：STDOUT（标准输出）和 STDERR（标准错误）。只要您的策略在运行期间有任何打印输出，平台就能将其呈现出来。
启动信息、框架日志、经纪商连接事件、交易所 API 错误、订单拒绝消息、重连尝试、运行时异常——只要您的应用将这些内容写入标准输出或标准错误，TradingHost 控制面板就能将其完整呈现。
STDOUT
正常的应用输出。包括启动信息、框架日志、经纪商连接事件、运行循环心跳、订单提交记录，以及您的策略向标准输出打印的其他任何内容。
STDERR
应用错误输出。捕获进程运行期间出现的交易所 API 错误、订单拒绝消息、身份验证失败、重连尝试以及运行时异常。
这一机制适用于所有支持的语言和框架。任何能够在容器内运行的程序，其产生的运行时输出都可以被 TradingHost 捕获。
容器兼容
- Python
- Node.js
- Go
- Rust
- Java
- C#
章节 03 · 它的具体用途
运行时日志能回答的关键问题
交易员在部署后常问的六个运维问题，以及运行时界面如何为您解答。
具体的可见性取决于您应用程序的输出内容。TradingHost 仅提供运行时日志展示界面，您的项目仍需负责输出有意义的应用级日志。
章节 04 · GitHub 驱动的闭环
专为基于 GitHub 的部署流程设计
只有将可观测性与部署流程相结合，它才能发挥最大作用。TradingHost 围绕 GitHub 原生工作流构建：您只需推送代码、部署项目，即可直接查看该部署产生的运行时输出。
这为您提供了一个包含三个关键节点的清晰运行闭环。
步骤 1
代码托管于 GitHub
您的策略、框架配置和部署清单均存放在 GitHub 仓库中。GitHub 是定义系统预期运行状态的唯一事实源。
步骤 2
部署在 TradingHost 上运行
TradingHost 读取仓库、构建容器并启动运行时。部署完成的瞬间，即代表您的最新代码迭代已正式上线。
步骤 3
运行时输出直观可见
运行中容器的标准输出和标准错误会直接呈现在控制面板中。您可以直观地确认部署是否启动、是否持续运行，以及其在运行期间输出的具体信息。
运行闭环
您的端
GitHub
策略、框架配置和部署清单的唯一事实源。
TradingHost
运行时容器
构建并运行部署，捕获运行中进程的 STDOUT 和 STDERR。
您的端
控制面板
呈现运行时输出，以便您查看部署已执行和正在执行的操作。
章节 05 · 经纪商与框架
适用于连接经纪商和交易所的交易策略
自动交易系统高度依赖外部连接。策略通常需要与交易所进行身份验证、建立 WebSocket 连接、调用经纪商 API、查询余额、提交订单、处理拒单，以及从暂时的连接中断中自动恢复。
TradingHost 的可观测性并非为了取代经纪商或交易所的账单报告。它的作用是让您能够清晰看到应用程序在与这些外部系统交互时的自身输出——而这往往是两端系统都无法直接提供给您的关键盲区。
章节 06 · AI 辅助工作流
专为 AI 辅助工作流设计
TradingHost 的可观测性同样支持 AI 辅助开发。当您使用 Cursor、Claude Code、VS Code 或基于 CLI 的 Agent 时，运行时输出将成为至关重要的反馈闭环。
Agent 负责协助修改代码，GitHub 负责托管唯一事实源，TradingHost 负责运行项目，而输出的日志则用于指导下一次迭代。每个阶段分工明确、各司其职。
迭代闭环
您 + Agent
修改代码
Cursor、Claude Code、VS Code 或 CLI 智能体提出修改建议并写入代码。
单一可信源
提交至 GitHub
变更提交到代码仓库。GitHub 决定了实际运行的内容。
TradingHost
在运行环境中运行
TradingHost 获取变更并在托管的容器运行环境中执行。
反馈
读取运行环境输出
STDOUT 和 STDERR 输出呈现在控制面板中。智能体读取这些输出并提出下一步修改建议。
运行环境产生的输出会反馈给智能体，用于生成下一步建议。这就是整个闭环。
MCP 的定位
MCP 是用于部署、可观测性和运行环境操作的控制与管理接口。智能体通过它来检查运行环境或触发重新部署。它不是交易执行路径。订单路由仍保留在您的策略内部，直接对接您的代码已连接的经纪商或交易所。
章节 07 · 它不是什么
运维可见性，而非性能分析
TradingHost 的可观测性专注于运行环境的运维。它帮助您了解已部署的交易进程是在运行、失败、重新连接，还是在产生预期输出。它并不试图涵盖其他所有功能。
运行环境日志涵盖的内容
部署是否已启动、策略是否进入运行循环、与经纪商或交易所的连接是否成功、是否发生错误、应用程序在失败后是否重新连接、最新的代码更改是否按预期运行。这些都是带有运维解答的运维问题。
- 它不是回测引擎。
- 它不是经纪商。
- 它不是策略构建器。
- 它不是投资组合分析平台。
- 它不能替代经纪商账单或交易所交易历史。
TradingHost 是自动交易代码的生产运行环境和基础设施层。策略创建和回测属于 AlgoBuilder。性能分析和交易员情报属于 TrackATrader。
常见问题
常见问题解答
TradingHost 提供了对运行中容器的运行环境输出的可见性，首先是 STDOUT 和 STDERR 日志。您的应用程序写入标准输出或标准错误的任何内容都可以从控制面板中呈现。
不是。TradingHost 的可观测性是针对运行环境运维的。交易分析、业绩归因、净值曲线和投资组合情报属于 TrackATrader 等分析工具。
是的。任何能够在容器内运行并写入标准输出的语言，其产生的日志都可以被 TradingHost 捕获。Python、Node.js、Go、Rust、Java、C# 以及其他与容器兼容的语言都共享相同的可观测性路径。
您的策略应当写入有用的运维输出。如果您的应用程序保持静默，那么从控制面板中可检查的内容就会变少。大多数框架开箱即用即可记录有意义的事件，因此对于许多项目来说，几乎不需要做任何改动。
可以，只要您的应用程序记录了这些错误。TradingHost 会直接呈现您的代码在与经纪商、交易所、框架和连接器交互时产生的输出。平台不会凭空制造错误，但也不会隐藏它们。
详细的日志记录和实现指南位于日志文档中。该页面涵盖了如何编写结构化输出、如何脱敏敏感数据，以及如何组织日志行以确保在大规模运行时依然清晰易用。
在 VPS 上，您通常需要登录服务器、找到对应的日志文件、滚动查找并拼凑出运行状况。而在 TradingHost 上，运行环境直接从容器中捕获 STDOUT 和 STDERR，并在控制面板中呈现，让可观测性成为运行环境的内置能力，无需再进行繁琐的手动排查。
不需要。作为平台运行机制的一部分，运行环境会直接从容器中捕获标准输出和标准错误。您无需安装日志 Agent、配置 Sidecar 或运行独立的日志传输工具，即可获得运行时的可见性。
不能。TradingHost 仅展示您的应用程序在与经纪商或交易所交互时输出的内容。订单、成交、余额和账单的权威记录仍以经纪商或交易所的数据为准。
可以。任何在容器内运行并向 STDOUT 或 STDERR 写入内容的框架，都与运行时的日志界面兼容。平台处理框架输出的方式与处理应用程序输出的方式完全相同。