Pysolate 的出发点是为 Agent 提供一个受控 Python 工具沙箱，让生成程序组合 Host tools。接下来的问题是：怎样设计环境接口与生成—执行反馈，让程序在预期的输入和状态变化下继续正确工作，减少模型返工，并将适用范围清楚的程序保存为后续 Agent 的工具？
这条研究线把接口设计、代码对变化的适应能力和工具复用连成一个循环。版本化工具箱是工程产物；主要研究对象是接口与反馈怎样影响产物质量及后续维护成本。已有小实验观察到了新状态复用和错误处理差异，尚未通过对照实验确认接口设计的因果作用。
这里的“可复用能力”指可调用程序，不是安全模型中的授权 capability。本文记录的是工程原型和早期实验，不是已完成的消费者 Agent、经济性比较或普遍正确性证明。
问题：复用会遇到哪些变化？
以采购报价为例。用户给出物品数量、交付期限和预算，程序读取当前报价，筛掉不可行供应商，再返回最低价的提案。若 B 降价、出现新供应商 C，或数量与预算在已声明的参数范围内改变，同一程序应读取新状态并重新选择，无需模型改代码。若新增“必须解释供应商信誉”的规则，则已超出原程序任务规格，可能需要重新生成。
这里不能用一个“兼容率”混合所有问题：
- 环境可执行性：包、文件和系统能力是否满足代码需求；声明不支持的能力时，模型能否使用已有等价能力完成任务。
- 变化后的任务正确性：目标和规则不变，输入或外部数据更新后，原程序能否重新计算正确结果。
- 失败处理与可组合性：超时、权限拒绝和返回结构违规，是否被误报为业务成功或正常空集；调用者是否知道下一步该怎么办。
输入通过 schema 检查只能说明形状合法。哪些变化仍在适用范围内，需要任务规格、接口契约和独立评价依据；harness 无法仅凭数值改变自动判定程序仍然正确。
用户规则 + 当前输入
↓
读取报价 → 检查数量 / 日期 / 预算 → 形成提案
↓
读取失败、接口不匹配、权限变化时如何报告？这个例子把问题分成三层：
- 任务规则由生成程序表达，例如如何筛选供应商。运行时不应暗中实现第二份采购策略。
- 执行边界由 Host 控制，例如本次调用可用哪些工具、调用预算和权限。保存程序不会保存或继承过去的用户权限。
- 任务是否达成由独立判据评价。程序正常结束，或与它自己的旧结果一致，都不等于满足用户目标。
还要区分依赖调用成功、程序正常结束和业务结果有候选。工具暂时不可用不一定需要重新生成程序；程序也可能合法重试或使用其他数据。因此，失败应带着足够上下文到达调用者，不能一概转换成“没有结果”。
方法方向：接口、生成、执行反馈与工具复用
两层执行边界，以及模型真正看到的接口
Pysolate 有两层相关边界。WASI 边界承接所支持的文件和系统交互，Python 构建与包集合共同决定 Guest 可执行的代码；自定义 Host Tool ABI 承接外部工具调用。这两层提供实验入口，不意味着需要修改二进制 ABI 才能改变 Agent 行为。
模型通常看到的是能力说明、Python 函数签名、类型、示例和执行反馈。研究应分开比较实际能力、接口呈现和反馈方式。改变全部三者后得到更高成功率，无法判断是哪一项起作用。新增类型说明也不会让原本不存在的包或系统能力自动可用。
拟议循环
任务规格 + 环境能力 + 工具接口
↓
Agent 生成 Python
↓
Pysolate 执行 / 开发变化测试
↓
契约错误与执行事实反馈 → 修改候选版本
↓
冻结源码 → 独立评价新状态
↓
在注明适用范围和测试证据后注册为工具
↓
后续 Agent 选择、传参、组合；Host 绑定当前权限
↓
运行失败或超出范围 → 报告 / 恢复 / 候选新版本运行时负责执行、能力约束与调用事实；harness 负责提示、测试、反馈和版本流程；业务规则仍由程序表达，任务评价来自独立规格。第一版直接完整重跑 Python，读取新数据，不做增量分析或新编译器。历史 replay 与新状态执行分别记录。
“升格为工具”只是增加稳定的调用入口、版本和说明，不增加权限，不移除隔离，也不证明对任意环境正确。接口所需依赖由当前调用绑定；外部修改仍由服务端提供实际支持的提交保证。当前没有真实下游消费者完成这一闭环。
先做哪一个对照
先固定可执行环境、底层工具能力、任务和授权，研究 Host 工具接口与反馈；环境能力缺失单独作为后续实验，避免同时跨越两层 ABI。
- 强简单基线：完整工具文档、普通参数化函数提示，加常规开发测试。
- 接口变化：相同业务能力与信息内容，用更明确的类型和结果/错误契约表达；若新增了原先没有的事实，单独标明它是信息增量。
- 反馈变化：在同一接口下，比较普通执行错误与结构化调用事实、变化测试反馈。限定相同开发预算，并区分更好的反馈和更多测试的收益。
先逐项比较，再测试有信号的组合。每次生成与开发结束后冻结代码，用未参与修复的新状态评价；消费者阶段也保留没找到适用工具、选错工具和回退的成本。无需先建全局 registry。
主要分别记录：首次成功率、后续变化中的无模型正确处理率、静默错误、模型返工次数和完整成本。故障场景中正确报告错误只算错误处理正确，不算业务任务完成；不能靠不断拒绝任务提高成绩。目标是得到可复用的接口设计经验，并交付一个小型生成工具闭环。
工具、技能、工作流与 runtime 的职责
文本 skill 是给模型阅读的指导；executable skill 保存可执行策略；workflow 编排多个步骤，也可以在步骤中保留模型判断；registry 负责发现和版本；runtime 负责执行与权限。若后续要做，当前较小的方向是在 Pysolate 之上加一层薄的可执行技能接口，把注册、检索和任务评判留在 runtime 之外。
可冻结的是规则、程序版本和输入/输出契约，不是外部状态或历史权限。每个新版本发布前可分开检查 schema 与依赖、程序行为测试、任务结果判据；生成测试样本本身不是独立 oracle。自我迭代应产出不可变新版本，经测试后再发布，并保留旧版本回退。回退代码版本不能撤销已发生的外部副作用。这是拟议边界，不是当前已实现功能，也不要求先建一套治理平台。
目前的数据与观察
真实生成程序的冻结评价
使用 DeepSeek Flash 对报价选择和库存补货两个任务族各生成两份独立程序，共四次真实模型请求。四份首版代码冻结后，在四个开发状态和十六个未提供给模型的评价状态上运行，共 20 次，预先固定的预期全部匹配（20/20）。每次都经过 CPython-Wasm 和只读 Host 工具，调用一次工具。原始模型响应与保存的首版源码逐字核对一致，没有为这组结果修改代码。
这个数字的单位是程序—状态运行，不是二十个独立任务：只有两个任务族和四份程序。它支持一个有限观察——在规则明确的小例子中，模型生成的普通函数可以在新数据和参数下复用。它没有证明真实工作负载中的泛化，也没有与每次重新调用模型或人工程序比较费用、延迟和维护成本，因此不报告节省比例。
工具失败与返回结构诊断
预设评价结束后，单独检查工具故障。对于同一种 provider 不可用异常，两份报价程序表现不同：一份向上传播错误，另一份捕获异常后返回“没有可行报价”。这说明原提示没有充分规定错误契约；它是接口缺口，不是模型违反明确规格的证据。
随后对四份冻结程序进行另一项后验诊断：Host 返回形状故意不符合工具约定，内容为错误对象。四次真实 Wasm 执行中，四份程序都正常返回业务空结果：报价程序报告无可行报价，补货程序返回空提案。该诊断不计入 20 次冻结评价，也不是故障频率估计。它提示仅检查最终业务值不足以确认依赖调用成功。优先可试的办法是由 provider 适配器校验返回、明确错误契约并保留 Host 侧调用状态；程序能否合理恢复仍需结合调用者的实际要求判断。
后续修复记录的边界
之后又发起三次模型请求，其中首个请求的记录缺陷导致响应和 usage 遗失；其余两次合计 9,372 tokens，不能作为三次请求的完整成本。修复过程中，子代理编辑版删除了模型源码中的顶层异常处理，属于语义修改。另存的主控对照版本仅移除尾部非 Python framing，不改代码语义；两种版本的结果分别复跑记录。这个过程是发现问题后的开发验证，不是独立盲测，也不能据此给出自动修复成功率。
已有机制、独立原型与未实现设想
Spine 现有机制是受控 Python 执行路径：Go/wazero 运行 CPython core Wasm Guest，通过 Host 注入的具名工具访问外部能力。Manifest 限定可调用工具，更细的业务授权由 Host 工具实现；本页原型中的权限检查由实验适配层提供。Prepared/COW 用于建立可重复的干净执行起点。主 Pysolate 仓库另有记录/replay 和调用预算等机制，不能全部当作 Spine 已提供的功能。这些机制不会自动保存任意程序现场、冻结外部服务，或证明业务规则正确。当前 Spine 基础 Guest 没有集成 NumPy，也不是 Wasm Component Model 组件。
独立研究 prototype是在真实 Pysolate Wasm 路径上运行冻结的模型生成 Python、状态评价和故障注入。它用于观察程序复用及错误如何穿过工具边界；不是已并入 Spine 的功能，更没有完成真实消费者 Agent 的调用闭环。
未来设想包括先接入一类重复任务和真实调用者，观察程序选择、输入传递、错误理解与维护成本；再评估接口类型、版本说明和测试能否覆盖观察到的失败。若未来确有跨语言或模块组合需求，可以另行比较 Wasm Component Model。类型化接口不自动证明业务语义、确定性或安全性。更远的执行方式变化目前未立项；在提出前需要具体的性质目标和收益证据。
自我批评：故事连贯，但还欠什么证据？
- 循环本身已有大量先例。 生成、执行反馈、测试、技能保存和迭代都可以继承现成方法。仅把它们串在 Wasm 上，足以做工程功能，却不足以证明研究贡献。应对照已有技能系统，找接口选择对后续复用的实际影响。
- “更兼容”容易掩盖不同问题。 包缺失、价格变化和 provider 故障需要不同处理。第一轮聚焦 Host 接口下的状态变化与错误语义，分别评分；不许用异常被成功报告替代任务成功。
- 目前的数据没有证明接口导致差异。 正常评价只有两个任务族和四份程序；后验注入故意违反了 provider 契约。它们支持故障机制诊断，不能证明普遍存在的问题，更不能据此主张一种接口更好。provider schema 校验、清楚文档和普通函数化都是应认真使用的简单基线。
- 适用范围不由 harness 自动发现。 普通函数可以适应新数据，但无法从几次通过推导所有“合理变化”。首版使用明确任务规格和开发者契约，区分可机械检查的条件与仅有测试支持的假设。不明的新语义不自动算兼容。
- 更长的提示、更多测试可能吃掉复用收益。 固定预算和同等质量比较，计入首次生成、修复、调用者选错工具和维护费用。缓存源码、直接重跑和模型局部继续均应作为对照；不预设复杂 harness 会胜出。
- Pysolate 的作用需要克制。 两层边界便于控制和观察执行，但不意味着 native 无法做到。适合交付的是执行基础上的接口与反馈研究；注册、业务检查和升级策略放在上层，避免 runtime 成为理解所有业务的执行器。
当前判断：适合继续做一个有用的小闭环。研究价值取决于能否得到跨任务可复用的设计结论，例如同等开发预算下，某种错误契约或反馈能减少后续静默错误和模型返工。如果收益仅来自修正一个 provider 的返回结构，就交付那个工程修复，不扩建通用框架。现阶段不新增编译器、不移除隔离，也不开展 native/Wasm 性能竞赛。
与 Jing 研究方向的关联
Jing 的公开研究介绍涉及 AI 生成代码，以及如何区分运行时动态生成的内容和需要固定保障的机制。这与本探索的分工问题相关：生成程序承载任务逻辑，Host 与运行时保留工具入口、权限和执行边界。两者关注点相邻，不代表本原型实现了她的系统或研究结论。
- XKernel 研究受约束的动态内核调优策略。可借鉴的提问方式是先明确允许动态改变的范围，以及哪些性质仍由固定机制保障；其证明不适用于任意 Python 程序。
- DepSurf 研究 eBPF 扩展与内核镜像之间的依赖失配。它提示“曾经能运行”不代表依赖在变化后仍兼容；这里可以继续研究工具语义、版本与错误契约，但当前没有实现类似分析。
- YoloFS 关注 Agent 可使用的信息与控制接口。与本探索的联系在于：哪些依赖失败事实应可靠地到达调用者，以及调用者如何决定重试或改写程序；这不是将文件系统机制直接移植到 API。
这些工作适合作为收敛问题的参照，不构成本探索的新颖性声明。进一步研究应从真实消费者工作负载中确定值得生成的逻辑，并与更简单的文档、类型约定和测试做对照。