它是什么
lightharness 是用光明把 DeepSeek Harness 的核心子系统逐个重新实现的 Agent 框架。它跑得起来：有 Web 界面、有 CLI、有流式输出、有工具调用、有插件系统。
但它的第一身份是压力测试。每写一个子系统，都会撞上「这门语言写不出来 / 写出来是错的 / 绕不过去」的地方，这些地方就是光明要改的清单。所以这个项目的产出有两份：一个能用的框架，和一份诚实的语言缺陷账。
能力范围
- 流式对话：逐字返回，支持多轮上下文、随时停止生成。
- 插件系统：侧栏可启停内置插件（状态落盘），展开卡片能看该插件给 Agent 挂了哪些工具；输入 owner/repo 就能从 GitHub 克隆并动态加载外部插件。
- 模型无关：任何 OpenAI 兼容接口都能接——DeepSeek、智谱、通义、本地 Ollama 都行。
- 热更新配置：页面上填 API Key、Base URL、模型名，保存即生效，不用重启服务。
- 零门槛试跑：首次启动默认 mock 模式，不需要任何 Key 就能看清界面和交互。
跑起来
cd dswork/lightharness
python 运行.py examples/运行Web服务器.light
# 自动打开浏览器：http://127.0.0.1:54321/?token=…
配置也可以直接写进 .env：
OPENAI_API_KEY=sk-xxxxxxxx OPENAI_BASE_URL=https://api.deepseek.com OPENAI_MODEL=deepseek-chat
- 实现语言
- 光明（LightLang）
- 状态
- 在研 · 子系统逐步补齐
- 入口
- Web 服务 / CLI
- 模型协议
- OpenAI 兼容
- 扩展方式
- 光明插件 · Git 动态加载
- 依赖
- light + lightplugin（兄弟目录）
一个容易踩的坑
它不是独立可跑的工程：会把光明编译器和插件生态当外部依赖，按兄弟目录查找。缺了 lightplugin 时，几十个 example 会集体报「模块找不到」——看着像代码坏了，其实只是依赖仓没并排放。部署到别处时用 LIGHT_MERGE、LIGHTPLUGIN 两个环境变量覆盖路径。
为什么这件事值得做
黑箱和工具箱，差别在出了问题之后
用别人的框架，你只能等它更新；用能读的框架，你可以当场改掉那三行不对的逻辑。
01
对一人公司
没有技术团队意味着没有人替你排障。当 Agent 行为不对时，你需要能顺着代码找到那一处判断，而不是在 issue 区等一个陌生人的回复。
02
对中文母语者
执行逻辑用中文写在文件里，工具定义、提示拼装、循环终止条件都是可读的句子。读得懂，才谈得上改得对。
03
对语言本身
这是一个真实规模的用户。它逼出了标准库缺口、并发语义问题、错误处理不一致——这些不可能靠写示例程序发现。