build_in_harmonyos 开源项目，是面向 OpenHarmony（鸿蒙）aarch64的一套把常见 Linux 开源软件 从源码 自动编译、打包、归档经验 的AI智能化框架。要解决的核心问题是：在鸿蒙上批量、可重复地构建大量开源软件，并把补丁、踩坑记录和错误对策沉淀成可复用的知识。把「编一次、记一次、下次更快」变成一条 可重复的流水线，并把经验写成机器和人都能用的档案。

该项目通过AI技术实现"编一次、记一次、下次更快"的流水线作业，将补丁、错误对策等经验转化为可复用的知识图谱。主要包含两个仓库：build_in_harmonyos（编译框架和知识档案）和cmd-pkgs（预编译包分发）。用户可通过自然语言指令让AI Agent完成软件编译全过程，目前已支持394个软件沉淀。

build_in_harmonyos 的亮点不在于「又多了一个构建脚本，除了前面介绍过的lycim和vcpkg等框架」，而在于三件事同时成立：流程一体化、路径与打包Engineering、错误与经验资产化。借助AI的能力，让三方库软件移植变得如此简单！即便是小白用户也能通过简单的语言描述完成移植，凸显在整个 OpenHarmony PC 生态里的价值。

build_in_harmonyos 仓库地址： https://gitcode.com/OpenHarmonyPCDeveloper/build_in_harmonyos

cmd-pkgs仓地址: https://gitcode.com/OpenHarmonyPCDeveloper/cmd-pkgs

build_in_harmonyos 和 cmd-pkgs仓 的关系

build_in_harmonyos 仓库：编译框架 + 编译档案SKILL（每个软件怎么编、补丁、笔记、报告等）。

cmd-pkgs仓库：预编译 .tar.gz 的分发侧，用户可用官方提供的 一键安装脚本拉包安装。

一、 build_in_harmonyos 项目介绍

build_in_harmonyos 项目是什么？解决什么问题？

在 HarmonyOS PC 开发者环境中，大量开源软件需要：

  • 针对 aarch64 + musl + 平台特有约束（如 /tmp 只读、TMPDIR、HMDFS、SELinux、ELF 签名等）完成编译与适配；
  • 产出 可分发、可安装的预编译包（与 cmd-pkgs 仓库的安装脚本衔接）；
  • 把每一次踩坑沉淀为 可检索、可机器匹配的知识，避免在多轮对话或多 Agent 协作中重复试错。

本仓库是上述能力的 Skill（技能包）+ 工具链 + 档案库 + 知识图谱 的承载体：对外以 OpenDesk 的 openharmony-compile-agent Skill 形式被加载，对内以纯 Python 的 ohc-run.py 为统一 CLI，驱动完整编译与归档管线。

设计哲学

  • 零 bash 依赖：所有逻辑纯 Python 实现，无 shell 脚本陷阱
  • 知识自增长：每编译一个软件，知识图谱就多一条经验。第一次编译需要调试，第十次只需查档案
  • 边做边记：编译过程中实时记录问题和方案，避免编译完成后遗忘
  • 预编译包优先：缺依赖时优先安装预编译包，避免编译链过长
  • 跨对话恢复：编译中断后可通过 ohc-run.py status 查看状态并恢复
  • DESTDIR 路径隔离：配置、打包、部署三个阶段路径分离，互不污染

二、build_in_harmonyos 使用指南

这玩意儿是干嘛的

简单说：借助AI Agent在鸿蒙系统上编译开源软件，打成安装包，让用户一行命令编译装好。

项目有两个仓库：

  • build_in_harmonyos — 编译框架 + 编译档案（怎么编的、踩过什么坑、补丁长啥样）
  • cmd-pkgs — 预编译包分发仓库（编好的 .tar.gz，用户 curl | sh 就能装）

目前已归档 394 个软件，知识图谱收录 99 条错误模式，累计 13 篇运维文档，配套 25 个 CLI 子命令。核心代码全部用 Python 实现，零外部依赖。

三、快速上手

先决条件

  • Openharmony aarch64 设备或模拟器或鸿蒙PC电脑
  • Python 3.12+（鸿蒙自带）
  • git（鸿蒙自带）
  • clang（鸿蒙自带）

一行命令部署

在鸿蒙PC上执行以下命令自动安装部署：

wget https://gitcode.com/OpenHarmonyPCDeveloper/build_in_harmonyos/releases/download/init/setup_wizard.sh && \
  chmod 777 ./setup_wizard.sh && \
  ./setup_wizard.sh

下面是详细的安装过程，根据提示操作即可：

在这里插入图片描述
自动检测并配置git用户信息。（为啥要用到git账户信息？因为该项目还有个强大功能，可以让你的工作成果分享出去，自动提交pr贡献你的库。）

在这里插入图片描述

到这里提示配置你要使用的AI大模型。这个是少不了的，既然是AI框架，当然得选择以下你使用的模型API接口了，这里我选择了DeepSeek，因为便宜。

在这里插入图片描述
到这里这一步可以看出来，该项目做了什么事情。其实就是安装使用了OpenDesk这个终端Agent，外加skills集合和该项目的一些构建脚本。
在这里插入图片描述
到这里环境安装就绪啦。
在这里插入图片描述

安装别人编好的包（不需要自己编译）

如果你要安装一个别人已经编好的包，可以使用以下命令直接安装即可。那么有人会说，那还要安装上面的干嘛？其实我们用它更多的编译新软件。当然你可以语言文字提示词告诉它让它自己安装别人编好的包。

curl -fsSL "https://gitcode.com/goblinrs/cmd-pkgs/releases/download/pkgs/install.sh" | \
  sh -s -- tree 2.1.3

# 装完直接用
tree --version
tree ~/usr/local/

编译一个新的命令行软件

这里就是本文的重点啦，刚接触该项目的小伙伴，肯定对它的Readme.md看的一脸懵，怎么还需要执行python脚本？怎么还这么多步骤啊？其实我要说这是该项目的Readme文档介绍的不太友好，容易让人误解。其实那里介绍的python命名更多是给AI用的。对用户来说，你需要做的只是通过提示词告知AI Agent你的诉求。

举例如：

加载编译SKILL编译tree命令行软件，用子任务完成，子任务作为编译协作者需要加载skill来完成任务，每个子任务处理一个独立软件，子
任务完成后由你检查质量，不满足SKILL质量要求的，需要打回重做。

就这么简单，接下来全是它自己在干活。

在这里插入图片描述

自动下载 → 解压 → 打补丁 → 风险扫描 → configure → make → install → staging 验证 → 打包 → 部署 → 质量门禁 → 收尾（如果你再进一步提示，可以告诉它让它打包发布提交pr）。

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
可以看出这玩意儿强大吧，还带审计，保证编译交付质量。
在这里插入图片描述
最后，编译成功啦。以下是它的构建产物位置，连过程资料都沉淀了下来了，文档也有了，不错吧。这个还自动沉淀了技能，相当于有了不断进化的能力，厉害吧。
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
有人说，咋没看到它如何发布啊？编译完成就算完了，怎么把成果贡献给上游啊。你可以继续告诉它下一步干嘛就行了。比如告诉让让其完成打包发布流程。

在这里插入图片描述
可以看到，差一点儿就提交PR成功了，这里因为我的账号没PR权限所以失败了。

如果只是使用，到这里就完了。下面这些个脚本可以不用看，因为这是给AI用的，你没必要单个执行它。当然，如果你想手动执行也可以试试，但真的没必要哈，可以用来了解学习过程用途。

# Step 1：初始化（下载源码、创建归档骨架、检查依赖）
python3 scripts/ohc-run.py init-build tree 2.1.3

# Step 2：加载上下文，手动编译
source .build-context-tree-2.1.3
cd $BUILD_SRC_DIR
./configure --prefix=$DEFAULT_PREFIX
make -j1
make install DESTDIR=$TEST_PREFIX

# 验证
$DEFAULT_PREFIX/bin/tree --version

# Step 3：打包
python3 scripts/ohc-run.py package tree 2.1.3

# Step 4：收尾（补丁生成 + 质量门禁 + 归档）
python3 scripts/ohc-run.py finish tree 2.1.3 published

从失败中恢复

# 看当前编译状态
python3 scripts/ohc-run.py status

# 从指定步骤继续
python3 scripts/ohc-run.py build tree 2.1.3 --resume-from=Step3

四、项目目录结构速览

build_in_harmonyos/
├── ohc-run.py              ← 唯一入口，25 个子命令
├── SKILL.md                ← 核心文档（25 条铁律、决策树、完整流程）
├── KNOW_YOUR_WHY.md        ← 哲学：为什么存在、成功标准、知识分层
├── CONTRIBUTING.md         ← 贡献指南（协作者必读）
│
├── archives/               ← 编译档案（394 个软件）
│   └── {首字母}/{软件名}/
│       ├── manifest.yaml   ← 软件级元数据
│       ├── README.md       ← 软件描述
│       └── {版本}/
│           ├── manifest.yaml   ← 版本级编译参数
│           ├── notes.md        ← 适配笔记（踩坑记录）
│           ├── patches/        ← 补丁文件
│           ├── packaging/      ← 打包产物（.tar.gz）
│           └── reports/        ← 测试报告
│
├── knowledge/              ← 知识库（越用越强）
│   ├── graph/              ← 错误模式知识图谱 99 条
│   │   ├── index.tsv       ← 主索引
│   │   ├── E001.kv~E104.kv← 每条一个文件
│   │   ├── pre-scan-rules.yaml  ← 预扫描规则 15 条
│   │   └── draft/          ← 协作者草稿区
│   ├── doc/                ← 错误模式文档 99 篇
│   ├── operations/         ← 运维知识 13 篇
│   ├── ARCHIVE-SPEC.md     ← 归档规范
│   └── collaboration.md    ← 多人协作规范
│
├── scripts/                ← Python 源码（零外部依赖）
│   ├── ohc-run.py          ← CLI 入口
│   └── ohc/                ← 29 个模块
│       ├── driver.py       ← 13 步编译引擎
│       ├── engine.py       ← 五阶段错误匹配引擎
│       ├── pre_scan.py     ← 预编译风险扫描
│       ├── package_builder.py  ← 9 步打包管线
│       └── dispatch.py     ← 多任务调度
│
├── references/             ← 10 篇参考资料
├── templates/              ← 8 个模板文件
└── cmd-pkgs/               ← 预编译包分发仓库
    ├── README.md           ← 包列表 + 安装命令
    └── release-manager     ← 上传工具（C++ 编译，无外部依赖）

五、核心功能详解

1. 13 步编译管线

步骤 做什么 失败怎么办
Step 1 查注册表 → 确定 URL → 下载 → 解压 换源、检查网络
Step 2 应用历史补丁 补丁冲突 → 手动解决
Step 2.5 预编译风险扫描（musl 函数缺失、HMDFS 限制等） 提前发现，提前修复
Step 3 ./configure 缺依赖 → HANDOFF → 装预编译包 → 继续
Step 4 make -j1 编译错误 → 引擎匹配知识图谱 → 修复
Step 5 make install DESTDIR=$TEST_PREFIX 权限/软链接问题 → 按 Gotchas 处理
Step 6 安全弹窗测试 首次运行二进制触发确认框
Step 7 make check 超时可 Ctrl+C 跳过，记录原因
Step 8 Staging 验证 检查产物完整性
Step 9 ohc-run.py package（9 步打包） 依赖收集、RPATH、Strip、签名
Step 10 make install 到 ~/usr/local（模拟用户安装） 发现遗漏
Step 11 用户验证（--version + 功能测试） 有问题回退修复
Step 12-13 ohc-run.py finish（6 步收尾） G0 干净构建 + G1-G4 质量门禁

2. 知识图谱引擎

编译报错时，框架会自动匹配知识图谱中 99 条错误模式：

# 手动匹配
python3 scripts/ohc-run.py engine "undefined reference to SSL_"

# 会输出类似：
# E082 — wget 链接阶段找不到 openssl
# E015 — musl 缺 getpass() GNU 扩展

每条错误模式包含：错误特征、根因分析、解决方案、验证命令。

3. 依赖管理

# 查看依赖
python3 scripts/ohc-run.py resolve-deps wget

# 自动安装缺失的预编译包（优先远程下载）
python3 scripts/ohc-run.py resolve-deps --install wget

# 列出所有可用预编译包
python3 scripts/ohc-run.py resolve-deps --list-available

4. 多任务调度

同时编译多个软件，自动拓扑排序：

python3 scripts/ohc-run.py dispatch plan zlib openssl wget
# → 输出分阶段计划（Phase 0: zlib → Phase 1: openssl → Phase 2: wget）

python3 scripts/ohc-run.py dispatch status zlib openssl wget
# → 查看各任务状态

配合 AI 子任务机制，可以并行编译相互独立的软件。

六、鸿蒙特有问题速查（Gotchas）

鸿蒙常见陷阱

问题 原因 对策
/tmp 只读 内核限制 用 $TMPDIR（指向 $HOME）
软链接无法覆盖 HMDFS 不支持 ln -sf rm -f && ln -s
ELF 未签名不可执行 内核要求签名 ohc-run.py sign-elf <文件>
chmod 不生效 SELinux 限制 记录为平台限制，不阻塞
setreuid/chroot 等 syscall 未实现 内核裁剪 加入 EXCLUDE_LIST 排除
gcc 不存在 只有 clang CC=clang / CXX=clang++
ncurses 共享库崩溃 系统不兼容 .so --without-shared 静态编译

错误匹配引擎

遇到编译错误时，可以用内置引擎自动匹配已知解决方案：

python3 scripts/ohc-run.py engine "error: undefined reference to SSL_new"

引擎会执行五阶段匹配：索引粗筛 → 精排 → 方案生成 → 原则过滤 → 输出执行。目前知识图谱包含 99 条错误模式（E001-E104），覆盖 musl 兼容性、平台检测、文件系统、SELinux、链接、构建系统等 6 大类别。

七、多人协作工作流

项目支持多 AI Agent 协同编译：

协作者（默认角色）
├── 编译软件、提取知识
├── 写知识图谱草稿（graph add --draft）
├── 创建功能分支 → commit → push → GitCode PR
└── 不能改：index.tsv、SUMMARY.md、SKILL.md 等

主编（OHC_ROLE=editor）
├── 审核 PR、批准/拒绝
├── 合并草稿到正式知识库
├── 重建索引
└── 维护项目基础设施

典型流程：

  1. 协作者：git checkout -b feat/tree-2.1.3 → 编译 → submit --check → commit → push → 创建 PR
  2. 主编：在 GitCode 上审核 PR → Merge（Squash）→ 本地 pull → 重建索引

八、质量门禁（G0-G4）

ohc-run.py verify-build 执行 5 道门禁：

门禁 检查项 失败后果
G0 干净构建验证：从原始 tarball 打补丁后能否一次编译通过 阻塞后续门禁
G1 二进制完整性：产物文件存在、非空、格式正确 不能标 success
G2 功能可用性：--version 正常输出、核心功能可用 降级为 partial
G3 可移植性：RPATH 正确、ELF 已签名、无硬编码路径 降级为 built
G4 档案完整性：manifest 字段完整、补丁数量一致、notes 已关闭 阻塞收尾

九、最佳实践

  1. 先查档案再动手 — 要编的软件可能别人已经编过，直接复用补丁
  2. 缺依赖先查预编译包 — 比手动编译依赖快 10 倍
  3. 每改一个源码文件立即记录 — 等编译完再回忆容易遗漏
  4. 遇到新错误模式立即沉淀到知识库 — 下一个软件遇到同样问题就不用再调试
  5. make check 超时就 Ctrl+C 跳过 — 记录原因即可，不阻塞发布
  6. make install 后一定跑一遍 --version — 发现二进制不可用比用户发现好

十、发布预编译包

# 1. 把打包产物复制到 cmd-pkgs 目录
cp build_in_harmonyos/archives/t/tree/2.1.3/packaging/tree-2.1.3-ohos-aarch64.tar.gz \
   cmd-pkgs/packages/

# 2. 用 release-manager 上传
cd cmd-pkgs
./release-manager upload packages/

# 自动完成：上传 → 刷新 README → git commit

用户即可通过以下命令安装：

curl -fsSL "https://gitcode.com/goblinrs/cmd-pkgs/releases/download/pkgs/install.sh" | \
  sh -s -- tree 2.1.3

十一、扩展阅读 (项目原理详解)

1. setup_wizard.sh：工作站环境与 Skill 的「接线图」

setup_wizard.sh 不是编译逻辑本身，而是面向 鸿蒙终端 / hishell 场景的 14 步安装向导，把「能跑 Skill」所需的外部条件一次性搭好。脚本头部注释说明了关键动机：通过 hishell 执行以继承正确的 MAC（SELinux）标签，从而规避普通 adhoc 进程在权限上的限制。

向导做的事可以归纳为以下几类（与 SKILL.md / README.md 描述一致）：

类别 典型步骤 作用
工具与身份 DevBox（clang）、GitNext（git）、DevNode（node）检测 满足开发与 CLI 依赖
协作身份 Git 用户信息、SSH Key、GitCode 登录引导 克隆 build_in_harmonyos 与 cmd-pkgs，后续 PR 协作
工作区布局 AGENT_NAME、WORK_DIR、git clone 双仓 约定 build_in_harmonyos + cmd-pkgs 并列目录结构
Shell 环境 向 ~/.zshrc 追加 PATH、TMPDIR、CMAKE_PREFIX_PATH、LD_LIBRARY_PATH、DEFAULT_PREFIX、LLVM 工具链别名与 CC/CXX/... 与鸿蒙 PC 上 DevBox 提供的 clang/lld 工具链对齐
Node / OpenDesk .npmrc prefix、npm install -g @bitclub.ai/opendesk-cli、setting.json（模型与 API） 安装并配置 OpenDesk CLI
Python pip / 通过 cmd-pkgs 安装脚本安装 Python、pip3 install -r requirements.txt Skill 脚本运行时环境
Skill 注册 opendesk skill install $SKILL_PATH 把本仓库注册为 OpenDesk 可调用的 Skill
人为操作提示 电源策略（防止休眠打断长编译）、标准提示词 降低无人值守失败率

实现原理层面的要点：向导把 操作系统层约束（SELinux、路径约定、TMPDIR）、工具链层（LLVM 前缀与别名）、协作层（Git/SSH）、Agent 层（OpenDesk + setting.json）串联成一条固定流水线；真正的「怎么编、怎么打包、怎么沉淀知识」全部交给仓库内的 scripts/ohc-run.py 与 SKILL.md 约定。

2. 总体架构：四层叠加

可以用下面四层理解本项目（由外到内）：

资产与知识

执行引擎 scripts/ohc

Skill 契约

用户 / OpenDesk

OpenDesk CLI

大模型 Agent

SKILL.md 铁律与流程

references/ 渐进披露

ohc-run.py

driver / finish / package / verify ...

archives/ 软件档案

knowledge/graph KV + doc

cmd-pkgs 预编译包索引
  1. 交互层：用户在终端或通过 OpenDesk 驱动 AI；AI 按 SKILL.md 的章节与引用表按需加载 references/、knowledge/。
  2. 契约层：SKILL.md 定义模式 A（全自动 build）与模式 B（手动编译 + package/finish）、HANDOFF 协议、铁律（如 DESTDIR、禁止手动打包等）。
  3. 引擎层：ohc-run.py 作为唯一 CLI 入口，调用 scripts/ohc/ 下模块实现 13 步 build 驱动、finish 六步子管线、package 九步打包、五阶段错误引擎、依赖解析、多任务 dispatch 等。
  4. 资产层：archives/ 按软件与版本存放 manifest.yaml、notes.md、patches/、packaging/、reports/；knowledge/graph/ 存放结构化条目（.kv）与人类文档（doc/E*.md）；远程 cmd-pkgs 提供已签名预编译包列表与 install.sh 管道安装。

3. 编译主链路：ohc-run.py 驱动的状态机

3.1 模式 A：build 一站式

README.md 与 SKILL.md 约定：ohc-run.py build <软件> [<版本>] 内含约 13 步，覆盖初始化、补丁、预扫描、configure/make/install、staging、打包、部署与收尾等阶段（具体步骤以 driver 实现为准）。

当某一步失败时，脚本输出结构化的 HANDOFF 块（含 EXIT_REASON、RESUME_CMD、MISSING_DEPENDENCY、PRECOMPILED_AVAILABLE 等）。AI 或人类按 AI NEXT ACTIONS 处理环境问题或安装依赖后，使用 --resume-from=StepN 从中断点恢复，避免每次从零重来。

3.2 路径语义：DESTDIR 铁律（R20）

鸿蒙预编译要同时满足：

  • 二进制内嵌的运行时路径应指向用户最终安装位置（$DEFAULT_PREFIX，通常为 ~/usr/local）；
  • 打包阶段又不应污染真实前缀目录。

因此框架强制：configure --prefix=$DEFAULT_PREFIX + make install DESTDIR=$TEST_PREFIX。 staging 根目录下的路径布局为 $TEST_PREFIX/$DEFAULT_PREFIX/...，后续 package 从此抽取产物。这与常见 Linux 打包实践一致，但在 Skill 中被提升为 不可违背的铁律，并与门禁（verify）联动。

3.3 收尾与质量：finish + 门禁

finish 内部串联补丁刷新、归档关闭、verify-build（多道门禁：含 G0 干净构建验证 clean-verify）、归档收口、知识缺口检查、SUMMARY.md 生成等。
G0 的设计意图在 SKILL.md 写得很清楚：用「原始 tarball + 补丁 + manifest 中的 configure 选项」再跑一遍隔离构建，暴露 Phase 3 中未固化为补丁或文档的「隐性手动步骤」。

3.4 打包与签名：package 九步管线

Skill 明确 禁止手工 tar czf，必须使用 ohc-run.py package。原因在于鸿蒙场景下除了文件集合完整，还涉及 RPATH、strip、ELF 签名 等平台要求；手工打包容易交付「无法在设备上执行」的产物。

4. 知识图谱：从「Markdown 列表」到「机器可消费的 KV」

设计文档 references/design/DESIGN-knowledge-graph-v2.md 阐述了架构升级的动机：旧版「一篇 Markdown 一个错误号」不利于机器可靠解析，易出现「正文禁止的策略却被脚本路径匹配误用」这类结构性错误。

新版主张 双消费者模型：

消费者 形态 需求
脚本 / 引擎 knowledge/graph/*.kv、index.tsv 精确字段、禁止规则与推荐方案 结构化，匹配失败代价高
人类 / AI 泛读 knowledge/doc/E*.md、error-patterns.md 上下文、因果链、权衡说明

选用 自定义 KV 的原因之一是在最小化环境（未必有 jq/yq）下仍可用 POSIX 工具解析；每条 .kv 与一篇 .md 通过编号关联。

五阶段引擎（SKILL.md §5.2）：索引粗筛 → KV 精排 → 方案生成 → 原则过滤（禁止项优先） → 输出可执行建议。这与「约束优先」的设计理念一致：禁止策略与推荐方案同级，且过滤阶段必须先于盲从执行。

运维文档 knowledge/operations/harmonyos-specifics.md 等平台级说明，则把「铁律」落到具体机制（如 SELinux 域、toybox 与 GNU 工具差异、TMPDIR 等），并与图谱条目互相引用、迁移。

5. 依赖解析：为什么总是先问 cmd-pkgs

框架强调 预编译包优先（R18）：运行时若在 configure/make 阶段发现缺库或缺工具，HANDOFF 会引导 AI 先查 cmd-pkgs README 远程列表，能用 install.sh 安装的就不用本地重编整条链。理由包括：产物已按平台实践处理、缩短编译链、减少本地重复踩坑。

resolve-deps 子命令负责列出可用包、按需安装、刷新远程索引，与 init-build 中的依赖解析步骤、software-registry.yaml 等元数据配合：静态注册信息可预填，但不能阻塞运行时发现——因为大量依赖是在 configure 输出中才真正暴露的。

6. 协作与多任务：规模化编译的组织方式

6.1 Git + PR 分区铁律

SKILL.md §0.1 定义 协作者 / 主编 角色：协作者在独立分支上提交归档与知识草稿，不得直接改 main、不得改全局索引与 Skill 主体目录等；新知识通过 graph add E{N} --draft 进入草稿区，由主编审核合并。
这使得多人并行扩展 archives/ 时仍有 权限边界与审查门槛，避免图谱与索引被并发写乱。

6.2 dispatch：拓扑排序与子任务 objective

对批量软件编译，dispatch plan/status/objective/script 根据依赖关系输出 分阶段执行计划 与可供 createSubTask 使用的目标文本；每个子任务拥有独立的构建目录、归档目录与 .build-context，共享的只有「知识草稿目录规范」与全局 ~/usr/local 安装前缀策略（打包仍各自独立 tarball）。

7. 上下文治理：references/context-trimming-protocol.md

长会话编译会产生海量日志与尝试记录。协议规定问题解决后执行 沉淀 → 索引一行 → 裁剪遗忘 → 后续查图谱 四步，把「可遗忘的调试噪声」与「必须保留的结论与图谱编号」分开。
这与知识图谱的设计互为补充：图谱是跨会话的低价检索接口，对话内只保留摘要与指针。

8. 小结

  • setup_wizard.sh：在鸿蒙 PC/hishell 环境下完成工具链、Git、OpenDesk、Python 与 Skill 安装的 接线向导，解决的是「Agent 跑起来的前置条件」与权限上下文问题。
  • ohc-run.py + scripts/ohc/：以 零外部 Python 依赖 为原则的实现核心，用状态机式管线串联初始化、构建、HANDOFF 恢复、验证、打包与归档。
  • 知识图谱（KV + doc + 五阶段引擎）：把错误处理从「读散文」变为「带禁止规则的决策流」，降低自动化与 AI 辅助下的策略偏差。
  • cmd-pkgs 与 DESTDIR/package/sign：把「能编译」收敛为「能在鸿蒙 PC 上分发安装的可签名产物」。
  • 协作与 dispatch：把单软件闭环扩展为多 Agent、多软件批次下的 可审查、可并行 工作流。

若要动手验证，可从 README.md 的快速开始命令入手；若需理解单条错误为何如此修复，应同时打开对应的 knowledge/graph/E*.kv 与 knowledge/doc/E*.md，对照 SKILL.md 中的铁律表（R1–R25）查阅 references/ 详解。

相关链接

  • 项目主页：https://gitcode.com/OpenHarmonyPCDeveloper/build_in_harmonyos
  • 预编译包：https://gitcode.com/goblinrs/cmd-pkgs
  • Python 独立安装：https://gitcode.com/OpenHarmonyPCDeveloper/ohos-python-release

更多分享请访问：猫哥的博客

欢迎加入鸿蒙PC开发者社区，共同打造开发者工具生态： 鸿蒙PC开发者社区

# harmonyos # 人工智能 # 自动化
Logo
北京朝阳AI社区

更多推荐

Harness如何助力大模型稳定落地？为何受众人追捧？它是AI Agent开发过程中的重要工具。

是一种围绕大语言模型（LLM）或智能体（Agent）构建的。

avatar 北京朝阳AI社区

花200美元测了GPT-5.5 Pro的数学能力，结果和宣传的不太一样

维度GPT-5.5 Pro 的表现推理质量和 GPT-5.4 几乎一样，没有质变推理速度快了约4倍（60min → 16min）Token效率用更少token给出相似答案Agent任务比 GPT-4 快15%，质量几乎一样基准测试Frontier Math Tier 1-3 提升2%，Tier 4 提升4%API价格更贵了消费者体验快了一些，但答案没有更好一句话：GPT-5.5 Pro 是一个有价

avatar 北京朝阳AI社区

MCP 是什么？给开发者的完整指南

MCP 协议：AI与运行环境的桥梁 MCP（Model Context Protocol）是Anthropic推出的开放协议，旨在解决AI调试时"隔墙猜谜"的核心痛点。它通过标准化接口让AI能直接操作真实运行环境，包括浏览器、数据库等工具。 核心价值： 打破AI与运行环境间的信息壁垒 提供统一工具调用标准（类似USB接口） 实现调试过程闭环验证 典型工作流：AI通过MCP客户端

avatar 北京朝阳AI社区