企业官网建设流程全解析

我给 Pi Coding Agent 做了一个桌面控制台：Pi-Harness

先说一下这个项目是怎么来的。我用 Pi Coding Agent 写代码已经有半年多，刚开始觉得这个命令行工具又轻又顺手，一个终端窗口就能干活：让它修 bug、补测试、写脚本、跨模块重构，它都能接得住。但用久了之后，一个感受越来越强烈——纯 CLI 的交互方式，已经撑不住复杂的多任务项目了。终端里几百行滚动的日志、被吞掉的上下文、看不到中间过程的黑盒执行，让我越来越没底。所以我给 Pi Coding Agent 套了一个桌面控制台，叫 Pi-Harness。

这篇文章不会讲太多天花乱坠的概念，就老老实实拆解一下：我为什么觉得 Coding Agent 需要一个“控制台”而不是一个“网页壳”，Pi-Harness 的通信架构是怎么设计的，四个核心功能模块怎么做才能真的提效，以及在开发过程中踩过的最有价值的五个坑。如果你也在用 Coding Agent 干活，或者准备给自己常用的 Agent 做一个类似的前端操作台，这篇应该能给你省不少时间。

1. 为什么我需要给 Pi Coding Agent 套一个 Harness

1.1 CLI 用久之后的三大真实痛点

第一个痛点是状态不可见。CLI 模式下 Pi Coding Agent 虽然会输出执行步骤，但本质上是“一坨文本流”。跑一个稍微大一点的改造任务，它能连续输出几百行日志，先扫了哪些文件、改了哪个函数、中间跳过了什么、有没有残留的临时命令，全靠用眼睛在终端里找。遇到上下文过长被截断的时候，连“它为什么停在这里”都不知道，只能重新起对话。

第二个痛点是审批机制太弱。Pi Coding Agent 操作文件或者跑命令，原本是偏向自主执行的。但真实项目里，我不可能放心让它直接改 dev 分支上的代码、直接执行批量 sed 替换、直接往项目里塞依赖。CLI 模式下虽然有确认提示，但那个提示混在日志里，一不留神就错过了，回车又敲得快一点，它就继续跑下去了。等我发现的时候，文件已经被改完了。这让我对它的信任度一直保持在一个很有限的范围里。

第三个痛点是任务和上下文几乎不可管理。一个终端窗口就是一个会话，终端关了，会话也就丢了。想让 Agent 同时处理两个仓库里的事情，就得开两个终端，然后自己记“这个窗口在干什么、那个窗口跑到什么阶段了”。一旦终端被误关或者电脑重启，之前的任务断到哪一步、已经改过哪些文件，完全没有记录。对长期维护的项目来说，这种状态是不可接受的。

可能有人会说我这是“把 CLI 用出了 IDE 的需求”，用 tmux 分屏不就解决了吗？我一开始也试过 tmux，但它只能解决“多个终端并存”，解决不了“结构化展示”和“安全审批”这两个核心问题。

1.2 “Harness”不是套壳，而是接线层

做这个项目之前，我先想明白了一件事：Pi Coding Agent 本身的底座是模型和工具链，它的能力边界取决于推理质量和可用工具。而 Pi-Harness 的定位，不是重新写一个 Coding Agent，也不是给它套个网页 UI，而是做一个介于“用户意图”和“Agent 执行”之间的接线层（Harness）。

这个名字是我故意的。“Harness”这个词在硬件和机械领域指“线束”，就是一根线缆把所有电气信号接到一起，让各个部件能互相通信。我做的东西本质上就是这个作用：把 Pi Coding Agent 的输出接到桌面的可视化组件，把我的审批和操作指令接回它的输入通道，顺带处理日志存储、会话快照、文件差异等周边能力。

想明白了定位，很多决策就变得简单了。我不需要给 Pi Coding Agent 增加任何内核层的东西，只需要在外部做一层包装器（wrapper），只要 Pi Coding Agent 暴露了标准输入输出接口，桌面控制台就能接管它。这也意味着 Pi Coding Agent 后续升级模型版本、增加新工具，都不会影响控制台本身的可用性。

1.3 和网页版 Agent 控制台的本质区别

市面上也有一些基于 Web 界面的 Coding Agent 控制台，比如某些服务商提供的云端 IDE 形态。用下来之后，我的判断是：网页版适合“托管型 Agent”，自托管 Harness 适合“本地型 Agent”。

原因其实很本质。网页版的 Agent 通常跑在别人的服务器上，代码也托管在云端，即使能连本地仓库，也是通过某种同步机制中转的。而 Pi Coding Agent 是直接跑在本地开发机上的，它能访问完整的本地文件系统、能执行本地 shell 命令、能调用本地的 git 历史。如果走网页中转，要么得开放内网端口，要么得把文件同步到远端，要么得给 Web 服务配复杂的鉴权——安全性风险和工作量都上来了。

所以我放弃了 Web 后端方案，选择了“桌面进程 + 子进程管理”的架构。Pi Coding Agent 作为本地子进程被 Pi-Harness 拉起，两者通过标准输入输出流通讯，不暴露任何网络端口，本地文件的访问也直接以当前操作系统用户的身份执行。这个安全性模型和直接用终端几乎一致，不会额外引入远程攻击面。

2. Pi-Harness 的核心架构：Tauri 壳 + JSON-RPC 桥

2.1 技术选型的取舍分析

技术选型我纠结了大概一周，主要在 Electron 和 Tauri 之间摇摆。先说说最后为什么选了 Tauri。

Electron 的优势是生态成熟、文档多、遇到问题几乎都能搜到答案。它的代价是包体巨大，内存占用常年 300MB 起步。我本来就是要一边跑编码 IDE 一边跑 Pi Coding Agent 再一边跑 Pi-Harness，再挂一个 Electron 桌面端，笔记本内存会很吃力。

Tauri 用的是系统自带的 WebView 渲染前端，后端是 Rust 进程，内存占用比 Electron 低一截。当时让我犹豫的主要是它的生态相对年轻，有些桌面端常见功能需要自己写 Rust 插件。但捋了一下我实际需要的功能——文件系统监听、子进程管理、系统托盘、系统通知——这些 Tauri 的 Rust 侧 API 都能覆盖，而且 Rust 侧处理子进程 IO 和管道数据流的体验比 Node.js 更可控。

最终定的技术栈是：

• 桌面外壳：Tauri 2.x，Rust 后端
• 前端：React + TypeScript + Vite
• 通信协议：JSON-RPC 2.0 over stdio
• 状态管理：Zustand
• 日志存储：SQLite（本地文件库）
• 差异对比：自定义 diff 渲染组件，底层解析 Git diff 格式

这套组合的好处是隔离层级清晰：Rust 只管进程、管道、文件系统这三件底层事，React 只管画界面和收集用户输入，JSON-RPC 是两者之间的契约。

2.2 桌面端与 Coding Agent 的通信协议设计

既然 Pi Coding Agent 本身是 CLI 工具，那 Pi-Harness 和它之间的通信就应该遵从“进程间标准输入输出流”这种最朴素可靠的方式。我在设计协议时做了一件重要的事：把 Pi Coding Agent 的普通文本输出和结构化事件输出剥离开。

这里要说明一下，Pi Coding Agent 的原始输出是一个文本流，里面既有普通 log（比如“正在扫描 src/utils.ts”），也有结构化 json 事件（比如“文件已修改，diff 如下”）。纯文本流对终端友好，但对桌面控制台不友好——我需要知道“当前执行到第几个步骤”“这个步骤是文件操作还是命令执行”“这个命令是否需要用户审批”。

具体做法是分两条通道：

1. Pi-Harness 启动 Pi Coding Agent 子进程时，用--output-format=json参数让 Pi Coding Agent 以 JSONL 格式输出事件流，每一行是一个独立事件。
2. 控制台前端只渲染 JSON 事件里已经解析好的结构化字段，不直接展示原始文本。

对开发团队来说，这套协议设计核心围绕三个方面延展：

• 标准化日志格式：日志中每次都将 task_id、run_id、event_type、payload 字段形成固定 schema。这样后续做任务搜索和报表聚合时，不用去猜每个日志行的含义。
• 强类型事件定义：不同的事件（diff_generated、command_executing、security_check_passed）通过 event_type 字段区分，确保前端可以根据事件类型做针对性渲染。
• 可扩展的审批协议：当 Agent 需要执行高危命令时，通过 command_requires_approval 事件请求控制台，控制台返回 approval_response 指令。这样规避了终端模式下确认提示淹没在日志流里的问题。

通信方式我用 JSON-RPC 2.0 作为总框架：

{ "jsonrpc": "2.0", "method": "command.approval.request", "params": { "task_id": "t_8f3a2c91", "command": "sed -i 's/old/new/g' src/core.ts", "risk_level": "high", "reason": "批量替换可能影响多个引用点" }, "id": 14 }

关键点在于，Pi-Harness 是控制着 Pi Coding Agent 的执行节奏的——只有收到approval_response，Pi Coding Agent 才会继续执行这条命令。这样等于把原来 CLI 模式下“可能看到提示也可能没看到”的不确定性，变成了一个强制性的同步审批点。

2.3 会话恢复与任务快照机制

CLI 模式最让人不爽的一个细节是：终端关了，会话就没了。Pi-Harness 里我实现了三层持久化机制，保证“电脑重启还能接着干”。

第一层是日志持久化。Pi Coding Agent 的每一行输出，不管是不是 JSON 事件，都会写进 SQLite 里的 logs 表。即便 Pi-Harness 崩溃了，日志文件也是完整落盘的，重新打开控制台后可以按时间线复盘之前发生了什么。

第二层是会话快照。每 30 秒，Pi-Harness 会把当前已经在内存中的会话上下文摘要（包括任务目标、已执行步骤、当前工作目录、已修改文件列表）序列化存储。这个快照不追求实时，只求恢复时能让你知道“大概进行到哪一步了”。

第三层是文件状态快照。在每次文件修改事件发生时，Pi-Harness 会把修改前后的 diff 存到数据库里。这意味着即使 Pi Coding Agent 改坏了文件，你也可以从控制台直接回滚到任意一个历史版本，而不依赖 git 分支是否有提交记录。

这套做得最重的其实是文件状态快照。因为 Pi Coding Agent 操作文件的时候，有些改动不会立刻触达 git 的可见状态，比如一个文件被改完还没来得及提交，另一个文件又在改动中，这种情况下 git status 看到的只是“一堆文件被修改了”，但具体每一步改了什么，只有 diff 历史可查。Pi-Harness 把 diff 存了下来，随时能回去看，而且可以按任务维度筛选，比如“看看天下午那两个小时里，Agent 到底动了哪些文件”。

3. 四个真正提升效率的功能模块拆解

3.1 任务流看板：把递归拆解摊开给你看

Pi Coding Agent 在执行复杂任务时，会内部形成一个任务拆解树：顶层目标是“完成登录模块重构”，往下拆成“重写 auth API”“调整前端路由守卫”“补充测试用例”，再往下拆成更细的子任务。CLI 模式下这个任务树只存在于上下文里，用户看不到。

Pi-Harness 的看板模块把这个隐式的任务结构变成了可视化的递进列表。左侧是任务树，右侧是对应子任务的执行详情。每个子任务会标注状态：等待中、执行中、已完成、失败、阻塞、等待审批。用颜色做了区分，一眼看过去就知道当前卡在哪儿。

做这个模块时我最注重的是“层级不能太多”。如果 Agent 拆成了七八层，看板就会变成一团乱麻。我的做法是：默认只展示三层——顶层目标、二级阶段、三级具体操作。更深层的细节不展示在树上，而是折叠进右侧详情面板。这样既能看到全局，又能在需要时下钻到具体某个文件改动。

任务看板的价值并不仅仅是“好看”，它改变了我和 Agent 的协作方式。以前我只能被动地等它跑完，现在我看到某个子任务状态一直是“执行中”，同时日志里在反复重试同一个操作，就能判断它可能陷入了死循环，及时介入中断、给新的指令。这等于在“完全放权”和“全程接管”之间找到了一个中间态。

3.2 文件差异对比与手动审批

这个模块是 Pi-Harness 里我使用频率最高的功能，也是我敢让 Agent 去碰重构类任务的关键依据。

每一次 Pi Coding Agent 产生文件修改，Pi-Harness 会在右侧面板弹出修改文件列表，每个文件附带一个 diff 视图。diff 视图不是简单地贴出 git diff 的文本，而是按 hunk 渲染，左右分栏展示改动前和改动后的内容。关键行会高亮，新增行和删除行分别用不同颜色标注。你可以在任何 hunk 上点击“接受该改动”或“拒绝该改动”，拒绝后 Pi-Harness 会把对应改动恢复为原始内容。

这个功能等于给 Agent 的写操作加了一道闸门。我实际的用法是这样的：让 Agent 自主跑分析任务和测试任务，但所有涉及代码修改的任务都必须在审批模式下执行。每个文件的改动我都会过一眼，同意之后再继续。一开始会觉得这个过程占用时间，但跑了一周之后我意识到，审过的 diff 其实逼着我更清楚地理解了 Agent 的思路，项目后期问题少了很多。

手动审批和“只看关键改动”要配合着用。真实的项目里一个重构任务可能改了几十个文件，每个文件都弹窗让你看会崩溃。我做了风险分级：只读操作和测试执行不需要审批，涉及 src 下核心代码修改的必须审批，涉及配置文件和依赖更新的必须审批，涉及删除文件的必须审批。分级的规则可以在设置里调。

3.3 资源消耗与 token 成本实时面板

Coding Agent 和聊天类 AI 最大的不同是：它会长时间运行，可能跑几十分钟甚至几个小时，而且它会消耗大量 token。尤其当你开的会话多了，token 消耗肉眼可见地往上涨。CLI 模式下你根本不知道每次对话花了多少 token，账单到了月底才心疼。

Pi-Harness 直接对接了 Pi Coding Agent 的事件流中的 token 使用统计事件，每个请求和响应的 token 数都会实时上报。我做了两个视图：当前会话视图和历史趋势视图。

当前会话视图显示三块：本会话已消耗 token 总数、输入 token 与输出 token 的占比、单次工具调用的平均 token 消耗。这三块数据能直接反映一个问题——Agent 是不是在“空转”。如果输入 token 特别高但是输出 token 很低，同时工具调用次数很少，说明它在反复读上下文但没有实际产出，这时候就可以考虑精简一下对话历史或者重新起一个会话。

历史趋势视图按天和周聚合，能看出每个项目前后端代码量增长和 token 消耗的关系。比如“这个月项目 A 的 token 消耗比项目 B 多了 40%”，要么说明项目 A 上下文很重，要么说明 Agent 在这个项目上的无用探索太多，就该考虑优化 prompt 或者缓存上下文。

3.4 多会话并行与上下文锚点

一个日常开发场景：我正在核心服务上做重构，同时想交给 Agent 去查一个边缘 case 的 bug；或者我想让它先跑一遍 lint 和测试，再帮我整理一下 changelog。CLI 模式下要同时跑这些基本靠多开终端硬扛。Pi-Harness 里我原生支持多会话并行。

每一个会话是一个独立的页签，页签里包含自己的任务看板、diff 列表、日志流、token 统计。多个会话之间互不干扰，因为它们各自对应一个独立的 Pi Coding Agent 子进程。

更重要的是“上下文锚点”机制。使用多会话时最头疼的问题是上下文断裂——你在这个会话里已经让 Agent 读了一遍项目结构和模块 A 的核心代码，另一个会话里又要重复让它读一遍。Pi-Harness 的上下文锚点允许你手动为某个会话标记“关键上下文节点”，比如“已经理解了权限模块的数据流”。

之后新建会话时，你可以选择继承某个锚点，Pi-Harness 会把锚点对应的上下文摘要注入新会话的初始提示中，相当于新会话带着旧会话的部分记忆启动。实际效果是跨会话协作时，Agent 不需要每次都从零开始了解项目背景，上手速度明显加快。

4. 开发过程中最值得记录的五个坑

4.1 流式 JSON 解析：被拆断的 chunk 打断

开发通信层时，我遇到的第一个问题就是 JSON 解析崩溃。Pi Coding Agent 的一行 JSON 事件可能很长，因为 diff 内容会内嵌在 payload 字段里，一个 diff 事件可能几万字符。我的 Rust 后端每次从管道读到数据时，并不能保证恰好读完一行完整 JSON——经常读到的数据是半截的，比如 JSON 字符串中间被截断，或者一次读到了两行 JSON 的一半拼接在一起。

第一次遇到这个问题时，我还以为是 Pi Coding Agent 的输出格式不稳定，导致控制台频繁解析失败、任务中断。排查了一下才发现，问题出在我自己的 IO 处理代码里。管道读数据的边界和 JSON 行的边界是两个完全不同的概念。

解决方案也很经典：引入一个缓冲行解析器。Rust 侧每次读到一个 chunk，先追加进一个 Vec，然后按\n切分，只有遇到完整换行符时才把那一行交给 JSON 解析器。半行数据留在缓冲区里继续累积。这个处理逻辑代码量很小，但它决定了整个通信层的稳定性。经验是：凡是做流式日志解析的，一定不要按“读到的这一段”去解析，要按“完整的行”去解析。

4.2 工具调用白名单：差点让 Agent 跑了不安全的命令

Pi Coding Agent 可以执行 shell 命令，这本来是我很早就知道的事情，但真正放手让它跑之后，我还是被吓到了。有一次我让它“清理一下测试产生的临时文件”，它开始执行rm -rf ./tmp/cache/，这看起来没问题；但紧接着我看到下一条命令是rm -rf ./，只是被一个脚本里的变量拼接错误导致的——如果当时我开了完全自主模式，这个操作就会把整个仓库删了。

这个事件直接促使我给 Pi-Harness 加了一层工具调用白名单机制。白名单支持两种模式：默认的“阻截风险命令”和可配置的“放行指定命令”。拦截规则包括：以rm -rf开头的命令、包含sudo的命令、包含curl ... | sh的命令、对 .git 目录的写操作等。每条被拦截的命令都会生成一个审批事件推送到前端，用户必须手动确认才放行。

我给其他开发者的建议很简单：无论你的 Coding Agent 有多聪明，让它可以自主执行 shell 命令之前，一定要先想清楚“如果它把路径拼错了会发生什么”。不给 Agent 加执行安全网，就是在拿仓库和安全开玩笑。Pi-Harness 也支持在审批时编辑即将执行的命令，这样即使 Agent 给了一条有问题的命令，你也可以手改一下再放行，不用回到终端重新输入一个完整的 session。

4.3 桌面进程的孤儿化：关掉窗口，任务还在跑

桌面应用的“关闭窗口”不等于“退出进程”这个坑，我相信很多人踩过。我在 Tauri 里开发时，点击窗口右上角的关闭按钮，窗口确实消失了，但后台的 Rust 进程还活着，Pi Coding Agent 的子进程也还活着。于是问题出现了：任务还在跑，用户以为任务已经停了，过了一段时间再打开 Pi-Harness，发现之前的任务已经执行完了，文件也改了，但用户完全不知道发生了什么。

这个问题从产品层面看是“违反直觉”的，从技术层面看是“子进程生命周期管理缺失”。我花了一个下午专门梳理关闭流程，最终的方案是：关闭窗口时弹出确认框，让用户选择“仅最小化到托盘”、“保留后台任务运行并退出控制台”、“终止所有子进程并退出”。前两种对应“后台运行场景”，第三种对应“彻底退出场景”。

这个设计虽然多了一步交互，但避免了“用户以为任务停了，实际上还在改代码”这种灾难性事件。后来我又加了一个保护机制：每次页面加载时，Pi-Harness 会扫描本地是否有残留的 Pi Coding Agent 子进程，如果有，会在界面顶部显示一个黄色横幅，提示“检测到上次会话未正确关闭，任务可能仍在运行”。这个提示帮我在崩溃后及时恢复现场。

4.4 长路径导致的加载异常

开发文件差异对比模块时，我遇到过一个很奇怪的 bug：某些文件修改后，diff 列表里不显示内容，只显示“无法加载差异”。一开始我以为是 diff 解析算法的问题，后来排查才发现，根本原因出在文件路径字符串上。

有些项目里文件的嵌套路径特别长，比如node_modules/engine.io-client/build/esm-debug/transports/websocket-constructor.browser.js这种，window 环境下完整路径超过 260 个字符，Rust 侧的std::fs::read_to_string直接报错，导致 diff 生成失败。在终端命令行下这个文件可以正常 cat，但在控制台应用里读取时，因为进程的运行权限和工作目录设计问题，触发了长路径限制。

解决办法是在 Rust 侧统一封装一个read_file_safely函数：优先用扩展路径格式，如果路径长度超限，先映射为网络路径形式再读取。另外，在项目初始化时，我会默认生成一个.piharnessignore文件，默认忽略node_modules、dist、build、.git这些大目录，避免无意义的文件监听和 diff 生成。这个文件的作用类似.gitignore，但不完全一样——它只控制 Pi-Harness 的监控范围，不影响 git 操作。

4.5 会话上下文长度与 token 膨胀

这是所有深度使用 Coding Agent 的人迟早会撞见的效率杀手。刚开始我把 Pi Coding Agent 的上下文窗口看成“越大越好”，觉得上下文越长，它能记忆的信息越多。结果跑真实项目时发现，当上下文接近窗口上限时，Agent 的响应速度明显变慢，而且回答质量急剧下降。经常出现的情况是：它记得“上午 10 点你已经改过 auth.ts”，但到了下午 3 点再问它“auth.ts 现在的鉴权逻辑是什么”，它会重新读一遍文件然后告诉你一个和上午完全不同的答案。

后来我在 Pi-Harness 里加入了一个“上下文压缩建议”模块。Pi-Harness 会监控每个会话的上下文 token 使用率，当使用率超过 70% 时，自动提示用户当前会话可能接近上下文瓶颈，并给出压缩建议：把已完成的子任务详情归档、只保留任务目标和结论摘要、清理过长的日志区间等。

这个功能相当于是给“对话记忆”做减脂。实际操作中，压缩一次上下文之后，Agent 的性能恢复立竿见影，输出质量明显提升。这事给我的启发是：Coding Agent 的能力上限并不只取决于模型的上下文窗口有多大，更取决于你如何管理和组织上下文。一个长时间挂机的 Agent 会话，到后期几乎都是在无效消耗 token。

5. 从“盯终端”到“盯看板”：这套控制台改变的工作流

5.1 人不再追着日志跑，而是按需下钻

用上 Pi-Harness 之后最大的感受是：我不再需要“盯”着终端输出了。终端模式下，你总担心错过关键信息，所以会时不时切到终端窗口看一眼，注意力被频繁打断。而 Pi-Harness 把信息分层之后，我可以只关注状态变化——任务树上的某个节点从蓝色变成黄色、侧边栏弹出一个“需要审批”的通知、token 面板的数字异常增长——这些才是需要我介入的信号。

平时代码重构的场景从“开着终端等它跑完再检查”变成了“看板上节点一个接一个变绿，然后我逐个检查 diff 给反馈”。这个过程切断了不间断的注意力消耗，我可以同时写自己的代码或看文档，只在需要审批时响应，注意力成本大幅降低。

5.2 现在推荐的 Agent 协作节奏

跑了小半年之后，我个人的最佳实践是：让 Coding Agent 负责结构清晰、重复度高、边际收益稳定的任务，比如接口字段补全、测试用例生成、跨文件重命名、代码格式调整。这些任务中间过程可控，出错了也能快速发现、回滚。而架构性决策、模块边界划分、对外接口设计这些任务，我仍然坚持自己先画好草图，再让 Agent 去执行具体步骤。

Pi-Harness 的审批模式和 diff 审查模块天然支持这种“人定方向、Agent 跑执行”的协作方式。任务拆解和排期由我定，Agent 负责把步骤落成代码，中间的每一个改动都经过我确认。这种模式跑了一个多月，项目里 Agent 改出的 bug 数量比我预想的低很多。

5.3 下一步想做的方向

Pi-Harness 目前已经满足了我的日常使用需求，但还有几个方向值得后续迭代。一个是引入更细致的“任务成本预估”——让 Agent 在执行前给出“这个任务预计消耗多少 token、需要多长时间”的估算，超过阈值就提前预警。另一个是把多会话的上下文锚点机制升级为“共享记忆库”，让不同任务之间可以复用之前已经理解的代码背景。还有一个想法是支持将某次任务执行生成的回放报告导出成 Markdown，方便团队评审时直接粘贴到文档里。

每写完一个项目回头复盘，总有那么几个瞬间会觉得“如果当初换个方案能少绕很多弯”，但技术上不存在完美的“万一”，只有一边踩坑一边迭代的实打实推进。Pi-Harness 从立项到可用，花了两周多的时间，最耗时的部分其实不是 UI 也不是功能模块，而是和 Pi Coding Agent 的输出流反复磨合的那一层数据解析和进程管理。但这一层打通之后，后面所有功能都变得顺理成章了。如果你也在考虑给常用的 Coding Agent 做一个类似的控制台，我建议从最小的通信桥接做起，先跑通“终端输出进桌面界面”这一件事，后面的一切都会接踵而来。