秉承在实践中学习，在项目中提高编程语言的综合能力的原则，准备在复刻deepseek harness项目的过程中，找到光明的不足，补足短板，让光明语言真正能够实战！请你修正一下，然后制定改进计划！

秉承在实践中学习，在写项目中提高编程语言的综合能力的原则，准备在复刻deepseek harness项目的过程中，找到light的不足，补足短板，让light语言真正能够实战！
已经让hy3 模型先摸了摸底，写了两篇文档： 在目录 G:\dswork\duan-light-merge ，一篇 复刻deepseek-harness难点分析.md ，一篇 复刻harness驱动_light升级计划.md 。
请你修正一下，然后制定改进计划！
可以把欲改进的功能拆分成3-4个独立的任务，我让其它AI agent也一起来帮我们完成任务！

hy3模型:用光明（Light）复刻 DeepSeek Harness：难点分析（v2 修正版）

修订说明：v1 由 hy3 起草，方向对但三处关键事实判错。v2 全部结论经源码实测复核，逐条附文件:行号。 复核范围：g:\dswork\duan-light-merge\light-merge（光明 v7）；harness 侧沿用 v1 的G:\github\deepseek-harness盘点。路线口径已由用户拍定：原生优先（原生二进制承载 harness 是北极星），转译路线仅作 MVP 保底。本文按该口径重排难度。

---

0. 一句话结论（v2）

真正的门槛不是"消灭 PyObject*"，而是原生 runtime 一行网络代码都没有。

src/llvm/runtime_typed.c（4344 行）已经有原生的 tagged value、list、dict、类、异常、协程调度器——原生复杂类型这一关已经过了。但它#include只有 stdio/stdlib/string/stdint/time/math/sys-stat/ctype/errno（src/llvm/runtime_typed.c:13-31），全文件epoll|kqueue|io_uring|pthread|CreateThread|WSA|sys/socket零匹配，select|poll|O_NONBLOCK|FIONBIO也零匹配。

一个 agent harness 的本质是「一根网络长连接 + 一堆子进程 + 一个事件循环把它们缝起来」。原生侧三者缺其二：没有 socket，没有 IO 多路复用。

---

1. v1 的三处事实错误（必须纠正）

错误 1：「原生 list/dict 仍是PyObject*」—— 不成立

c_backend.py:15-31确实有那张表：

但——PY_TYPE_TO_C在整个文件里没有任何引用点，是死代码。实际生效的是_type_to_c()（c_backend.py:156-181）与_infer_type()（:506-509），复合类型返回void**；生成的 C 里没有#include <Python.h>（运行时头见:34-38）。

更要紧的是：c_backend.py根本不是原生主路线。它的链路是「光明 → Python 源码 →ast.parse→ C」（:98-114、:619-693），只支持 int/str/if/while/range-for/递归函数，字典恒为'{0}'（:268-269）、in生成/* in */（:310-311）、Pow生成非法 C（:287）、无类无异常。它的 60 个测试（tests/unit/test_c_backend.py，733 行）全是字符串断言，没有一个真调 clang 编译运行。

结论：把c_backend.py:22-23当作"原生 runtime 的 Python 依赖证据"是找错了地方。这条 P0（v1 的 U2「消灭 PyObject*」）应当删除。

错误 2：「无自研事件循环」—— 一半不成立

runtime_typed.c:4006起就是协程/异步分区，已经有：

• LightCoroutine（:4027-4043）、LightFuture（:4045-4053）

• LightScheduler{ run_queue, all_coros, num_coros }（:4056-4063）+ 全局单例g_scheduler（:4063）

• dv_scheduler_run()单线程取队首（:4233-4243）、dv_coro_await（:4186）、dv_coro_run_to_completion（:4246）

• 恢复机制 Duff's device +resume_point（:4019），上限DV_MAX_COROUTINES 256（:4024）

也就是说协作式协程调度器已经有了。缺的是它右边那一半：没有 IO 等待队列——协程只能靠"主动 yield"切换，不能靠"socket 可读"唤醒。这才是准确的缺口描述。

错误 3：「light7 compile --native」—— 该命令不存在

--c/--native只存在于light6.py:19-20, 324-329, 348-388，而pyproject.toml:67-69的 console_scripts 只有light = cli.light:main与lightc = cli.lightc:main。安装后的用户拿不到light7命令。真正的原生入口是cli/light.py:1295-1298的compile --backend {antlr,src,llvm,llvm-typed}（分派见:340-381）与light pkg native --target（:1348-1351）。

顺带两条同类问题：

• --target wasm（cli/light_unified.py:1056）参数存在、实现缺失：compile_with_src（:365-407）只特判llvm，wasm/js全落入 else 分支静默生成.py。src/wasm_target.py（577 行）是 Pyodide 方案，不产.wasm，且除一个测试外无任何生产代码引用。

• 两条 LLVM 路径并存：src/llvm/（主力，真 IR，codegen.py974 行 +codegen_typed.py3372 行）与antlrparser/llvm_codegen.py（旧，i8* 字符串类型系统），被不同 CLI 分别调用（src/compiler.py:1510-1528走旧路径，cli/light.py走新路径）。根目录llvm_backend.py名不副实——它不生成 IR，只是"找 clang 编译 C 文件"的包装（:27-50, 131-138）。

---

2. v1 漏掉的真阻断项（比 v1 全部 P0 更致命）

这几条是实跑探针（编译 + 执行）发现的，v1 一条都没提。它们的共同点：不是"性能不够好"，而是"这行代码写不出来"。

2.1 光明的异步代码没有启动入口（🔴 最高优先）

语法层是齐的：异步 段落→async def（src/parser_stmt.py:330-345、src/code_generator.py:1409）、等待 X→await（src/parser_expr.py:423-449）、异步 遍历→async for（:339-342）、使用 异步→async with（:4851-4855）、异步 作用域→asyncio.gather（:3347、code_generator.py:1998-2019）。

但没有asyncio.run等价物：

• 顶层等待 主()。→ 模块级裸await 主()→ 实测SyntaxError: 'await' outside function

• 运行异步(...)不存在（ParseError）

• 创建事件循环/事件循环运行只出现在src/lexer.py:238-239的标识符白名单里，codegen 与 stdlib 零实现

• 退路也堵死：引 Python：asyncio.run(主())中 L4 块exec到独立 ModuleType 命名空间，看不见光明侧定义的主→ 实测NameError: name '主' is not defined

tests/test_async.py的异步测试全是断字符串（assert 'async def' in py_code），唯一真跑的test_yield_simple_values:529-548跑的是手写 Python 而非光明产物——所以这个洞没有任何测试守着。

含义：今天用光明写不出任何能跑起来的 async agent loop。转译、原生两条路线同时被这一条卡死。

2.2yield from静默错编

生成 从 乙()。→yield 从+乙()（两条语句），生成 全部 乙()。→yield all(乙)()。编译期零提示，运行期才炸。生成器委托是流式解析器的刚需（SSE 分帧、chunked 解码天然是嵌套生成器）。静默错编比报错更危险。

2.3映射/筛选参数顺序反了

映射([1,2], 接收 数：返回 数 乘 2)→map([1, 2], lambda ...)→ 运行时TypeError: 'function' object is not iterable。定义在src/keywords.py:355-356（arity=2），codegen 按源序直落。两个最基础的高阶内置动词是坏的。

2.4 调用侧关键字实参不支持

打印(甲 = 1)→ 实测意外的标记: 「=」（src/parser_expr.py:2564-2592有 C 风格 kwarg 代码路径但未生效）。一个有几十个可选项的框架（超时、重试、并发度、工具过滤器）没有 kwargs 极难写。

2.5 没有global/nonlocal等价物

函数内设 计 为 计 加上 1编成计 = (计 + 1)→UnboundLocalError。跨作用域可变状态只能靠对象属性或可变容器兜。

2.6 泛型是空壳、可空类型?词法层不存在

类 栈[T]：→class 栈:（generic_params在src/parser_stmt.py:3913-3918, 4285-4290收集了但 codegen 不消费）；文本?→LexerError: 未知字符 '?'（尽管docs/可空类型unwrap系统.md声称支持）。类型系统在大型框架里只能当注释用。

---

3. 光明真实能力盘点（复核后）

强项（可以放心用）

• 异常体系：try/catch/finally/else、多 catch、捕获 类型 as 变量、自定义异常继承链、裸抛出、抛出 X 从 Y—— 全部实测通过。（docs/known_issues.md:27说不支持 as 变量，该文档已过期）

• 类与对象：继承、多继承（仅继承 甲, 乙形式）、己/父、构造、接口/协议→ABC+abstractmethod（code_generator.py:1788-1837）、@静态方法/@类方法/@特性/@抽象、私有名改写、迭代器协议__迭代__/__下一项__

• 闭包/高阶函数：端到端跑通（造(5)(3)→8）、lambda 多参、函数作为值、字典里放 lambda

• 数据结构：list/dict（方括号即字典）/set/tuple 字面量、解构赋值、列表/字典/集合推导式、切片、[等待 甲(项) 遍历 项 之 源]异步推导式

• 字节与字符串：b"..."字面量（src/tokens.py:22）、.编码()/.解码()、f-string 插值

• 装饰器 / 上下文管理器 / 定义侧*args **kwargs

• 原生 runtime：taggedLightValue（8 种 type，runtime_typed.c:37-52）、算术/字符串/列表/字典（:1637）/文件/系统/异常类体系（:2783）/类与接口（:3427）/运算符重载/isinstance/协程（:4006），228 个导出函数，跨 win32-linux-darwin × x86_64-aarch64

• LLVM 后端是真 IR，50 个_gen_*覆盖到类实例化、try/throw、async 段、await、async scope；test_llvm_exception.py（12 例）与test_llvm_async.py（12 例）是真端到端（IR → clang → 跑 → 比对 stdout）

弱项（复核确认）

• 标准库 0% 由光明写成。56 个.light里 55 个只是导出清单（stdlib/文件系统.light:1-7自述"本模块实现见同名 .py"）；唯一有真实现的stdlib/列表工具.light已被后加的stdlib/列表工具.py遮蔽——stdlib/_light_import_hook.py:140-142规则是.py绝对优先。全仓PURE_LIGHT_ONLY = 0，即该导入钩子的.light分支在 stdlib 范围内是死代码。

• HTTP 无 SSE。顶层stdlib/HTTP.py14 个函数基于 urllib，无任何 stream 参数；stdlib/lightpub/HTTP客户端.py:110-114有iter_content转发，但无iter_lines，全仓event-stream|EventSource|SSE|chunked在 stdlib/contrib 中零命中。没有任何 SSE 帧解析器。

• JSON Schema 校验是玩具。stdlib/JSON.py:777-795的JSONSchema验证只认type/properties/required/items四个关键字（:798-829），缺 enum/范围/pattern/format/oneOf/anyOf/$ref/additionalProperties，返回裸 bool不产出错误路径，且:794一个except:把实现 bug 一并吞成"校验失败"。

• 事件总线不完整。stdlib/lightpub/事件驱动.py:32-46只有注册（往 asyncio loop 对象上 monkey-patch_events），没有 emit/dispatch；能用的 pub-sub 是stdlib/lightpub/消息队列.py（import queue/threading）。插件系统在contrib/插件系统.py（340 行，含注册扩展点:155/触发扩展点:161/@扩展点:214/热更新:279）——有，但在 contrib 不在 stdlib，且是 Python 写的。

• PTY 与沙箱彻底为零。全仓openpty|winpty|conpty|import pty|seccomp|landlock|prctl|ptrace仅 2 处命中，都是 SFT 训练语料里的噪声。

• 原生侧无网络无线程（见 §0）。转译侧有stdlib/网络.py、stdlib/lightpub/Socket.py的 socket 薄封装。

• 模块系统拒绝循环依赖（src/module_resolver.py:45-57, 573-675, 837-845抛CircularDependencyError）。65 包级框架若照搬 harness 的包间引用图，会撞上这条。

• 推导式介词与遍历语句不一致：推导式只认之/在，不认于；遍历语句认于。同一概念两套介词。

---

4. 难点重排（原生优先口径）

#	难点	阻断性	light 现状（实测）	难度
1	异步代码无启动入口	🔴 硬阻断，写不出第一行	语法全齐，asyncio.run等价物零实现	★★
2	原生 socket + 非阻塞 IO	🔴 原生路线硬阻断	runtime_typed.c零网络零多路复用	★★★★★
3	原生调度器接 IO 唤醒	🔴 与 #2 同生死	协程调度器已有，缺 IO 等待队列	★★★★
4	前端小缺陷群（yield from / kwargs / 映射筛选 / global）	🔴 逐个都能卡死具体模块	见 §2	★★
5	SSE / chunked 流式解析	🟠 LLM 对接必需	零	★★
6	进程执行引擎（进程组 / 信号升级 / 有界输出+spill / taskkill）	🟠 tool 执行必需	subprocess 薄封装，无进程树管理	★★★
7	JSON Schema 校验	🟠 tool 参数校验必需	四关键字玩具版	★★
8	事件总线 / 插件（Cordis 等价）	🟠 可插拔架构地基	contrib 有 Python 版，需提级 + 光明重写	★★
9	MCP 客户端协议栈	🟡 生态互通	零；转译路线可导入 mcp	★★★
10	标准库自举率 0%	🟡 "语言能力"这件事本身	.light全是清单，导入钩子分支死代码	★★★
11	PTY	🟡 交互式终端	零	★★★★
12	沙箱 landlock/seccomp	🟡 安全边界	零；转译路线可 ctypes	★★★★
13	循环依赖硬拒绝 / 泛型空壳 / 可空?缺失	🟡 大型项目可维护性	见 §3 弱项	★★★

难度 ★ 与阻断性是两个正交维度：#1 和 #4 难度只有 ★★，但它们卡在最前面——先修最便宜的阻断项，才能开始暴露真难点。

---

5. 判断

1. #1 + #4 必须最先做，加起来是编译器前端的一批点状修复。它们成本最低、解锁面最大：修完，转译路线上的 agent loop 立刻可写，原生路线的前端（src/llvm/compiler.py共用同一套 lexer/parser）同步受益。

1. #2 + #3 是原生优先口径下真正的核心工程，也是 v1 完全找错了位置的地方。目标不该是"消灭 PyObject*"（那是死代码），而是给runtime_typed.c补上 socket + 跨平台 IO 多路复用，并把g_scheduler从纯协作式升级成"有 IO 等待队列"的事件循环。这一步做完，"原生二进制跑 agent loop"才从口号变成可验证目标。

1. #5–#8 走双实现：先用.light写一遍（同时喂给转译与原生两条后端），这既是 harness 的必需件，也顺手把「标准库自举率 0%」这条从 0 往上抬。新增能力一律不许留同名.py影子，否则_light_import_hook.py:140-142会让光明版永远不被加载。

1. #9/#11/#12 押后，理由是它们都是"接一个已有的外部协议/系统能力"，纯工程量，不产生语言层面的信息。真正能逼语言变强的是 #1–#8。

1. 一个必须承认的现实："原生二进制跑完整 harness"在 #2/#3 落地前是不可能的。所以路线不是二选一，而是同一份.light源码、两条后端并跑——转译路线负责"今天就能跑、暴露语言缺陷"，原生路线负责"最终目的地"，用同一套端到端用例双跑，谁跑不过谁就是待补能力。这样北极星不变，又不用等 runtime 完工才开始写 harness。

---

v2 定稿 2026-08-21。所有文件:行号均为本次源码实测。配套改进计划见复刻harness驱动_light升级计划.md，可分发任务书见任务书/。

comate复核

两篇文档已改写为 v2，另产出 4 份可直接分发的任务书。所有结论都经源码实测复核（含实跑编译+执行探针）。

hy3 判错的三处（最要紧）

1. 「原生 list/dict 仍是PyObject*」不成立。c_backend.py:22-23那张PY_TYPE_TO_C表全文件零引用，是死代码；实际走void**，生成的 C 里连#include <Python.h>都没有。而且c_backend.py根本不是原生主路线（它是 光明→Python源码→ast.parse→C 的玩具，60 个测试全是字符串断言、无一真调 clang）。真原生路线是src/llvm/+runtime_typed.c（4344 行），原生 tagged value / list / dict / 类 / 异常 / 接口早就有了。所以 hy3 的头号 P0「消灭 PyObject*」是个伪 P0，已删。

2. 「无自研事件循环」只对一半。runtime_typed.c:4006-4246已有协程 +LightScheduler+g_scheduler+ Duff's device 恢复。缺的是右半边——没有 IO 等待队列，协程只能主动 yield，不能被 socket 可读唤醒。

3.light7 compile --native这个命令不存在。只在light6.py里，而pyproject.toml:67-69只有light/lightc两个入口。

hy3 完全漏掉的头号阻断

光明的异步代码没有启动入口。语法齐全（异步 段落/等待/异步 遍历/使用 异步/异步 作用域全通），但顶层等待 主()。→SyntaxError: 'await' outside function；无asyncio.run等价物；创建事件循环只在src/lexer.py:238-239白名单里、后端零实现；退路引 Python：asyncio.run(主())也堵死（L4 块 exec 到独立命名空间，看不见光明侧的主）。

今天用光明写不出任何能跑起来的 async agent loop，转译和原生两条路线同时被这一条卡死。而且tests/test_async.py全是断字符串（assert 'async def' in py_code），这个洞没有任何测试守着。

同批还有：生成 从 X()（yield from）静默错编成两条语句、映射/筛选参数序反了直接 TypeError、调用侧f(甲=1)不支持、无global/nonlocal。这几条难度都只有 ★★，但卡在最前面。

你按「原生优先」拍定后，路线是这样落的

同一份.light源码、两条后端并跑。转译负责"今天就能跑、立刻暴露缺陷"，LLVM 原生负责最终目的地，同一套端到端用例双跑，谁跑不过谁就是待补能力。北极星不变，也不用等 runtime 完工才开始写 harness。

原生优先下真正的 P0 换成了：runtime_typed.c一行网络代码都没有——sys/socket|epoll|kqueue|WSA|pthread与select|poll|O_NONBLOCK全部零匹配。

4 份任务书（任务书/目录，文件归属互不重叠）

• A 前端阻断清障（关键路径，优先启动）—src/lexer.py/parser_*/code_generator.py。修异步入口、yield from、映射筛选、kwargs、global。LLVM 后端共用同一套前端，所以两条路线同步受益。
• B 原生网络+事件循环—src/llvm/runtime_typed.c。socket 族 → poller 抽象（先 select 兜底再换 epoll/kqueue/WSAPoll）→ 调度器接 IO 唤醒 + 定时器 + 破 256 协程上限。已提醒 Duff's device 下"跨挂起点局部变量保活"是最易出错处。
• C SSE + LLM 客户端 + JSON Schema— 全部新建.light。
• D 进程执行引擎 + 事件总线/插件— 全部新建.light。

一条我加进去的硬约束

stdlib 里"运行期真正由光明代码提供"的模块数是 0/134 = 0%。56 个.light里 55 个只是导出清单；唯一有实现的列表工具.light被后加的列表工具.py遮蔽——_light_import_hook.py:140-142规定.py绝对优先，所以那个钩子的.light分支在 stdlib 范围内是死代码。

所以任务 C/D 的铁律是：新模块只建.light，绝不建同名.py；引 Python计数恒为 0。绕不过的地方登记成语言缺陷交回任务 A。这才是"在实践中暴露短板"——用逃逸口掩盖缺陷等于把整件事的意义废掉。度量就两个：语言自举率和逃逸计数。

另外顺手登记了 7 条会持续误导后来者的仓库债务（llvm_backend.py名不副实、两条 LLVM 路径并存、--target wasm静默生成.py、test_llvm_pipeline.py:41-75断言returncode in [0,1]成败都算过、docs/known_issues.md:27已过期等），在升级计划 §5。

M3 的 agent loop + session 留给主线自己做，当压力源。