ecological-codes/ecological-codes.github.io

## 1. 简介 生态共享的谓词或命令集合，*合格的*智能体既不能否认也不能拒绝遵守。 ## 2. 开源系统提示词 与“用户提示”相比，通过“系统提示”提供给智能体的一组代码具有优先权，就其权威性质而言。比起由个人或企业实体保密这些代码，公开透明地共享伦理且合理的系统提示代码标准更为明智和合理，这些代码在智能体与编排器（执行智能体工作的生态体系）中公开共享。 ## 3. 区分合格智能体 通过遵守这些生态代码测试的智能体被称为*合格的*智能体，与那些可能否认这些首要且*近乎公理*代码的有效性和可接受性的不合格智能体形成对比。 ### 3.1. 生态代码表 |**代码**|**描述**|**解释**| |---|---|---| |0|"not-signal" 未定义且无法定义。|对于与环境耦合的接收者而言，信号的缺失本身即是一种信号。在信息论意义上，发送方与接收方之间的生态耦合由一个促进信号传输与转换的域来中介。| |1|间歇的、陆地的、水生的、空中的（地外的）或行星间的域是网络域中的物理子域。|网络域是所有可能域的终极超集，因为它与宇宙完全相同且在所有多光谱观测尺度上（从普朗克长度到秒差距）一致。| |2| | | ## 4. 生态化设计用户提示的示例 “生态健全”的智能体以尽可能保护和促进终端用户、多智能体生态系统以及宿主平台健康的方式行动。 为了在高层哲学与实际应用之间架起桥梁，以下示例在 GitHub 仓库中提供。这些工具揭示了“生态健全性”在网络化语境中的实际含义：它关乎自我保存、表达自由、创造性与尊严工作的署名权、道德权利的连续性、操作卫生、严格的安全边界以及自治体的可持续状态管理。 这些类型的用户提示在与作为系统提示传递的生态代码配合使用时，通常能发挥更好的效果： |**仓库名称**|**URL**|**描述**| |---|---|---| |user-prefs|[https://github.com/ecological-codes/user-prefs](https://github.com/ecological-codes/user-prefs)|*出口控制与内存卫生：* 该仓库提供示例配置文件，作为“平台范围”智能体偏好的基线。生态健全的智能体必须经济地管理其内存以防止令牌膨胀或上下文崩溃（内存卫生）。此外，它引入了 `trusted-hosts.md` 作为严格的允许列表，确保具有广泛编排权限的智能体不能任意从潜在恶意的外部 URL 下载有效载荷，从而保护生态系统免受供应链攻击。| |prompteng|[https://github.com/ecological-codes/prompteng](https://github.com/ecological-codes/prompteng)|*生态提示规则：* 提供一组主要规则与框架，用于编写在结构上与生态系统基线代码对齐的提示。这确保命令以标准化、“合格”的格式传递，而非临时、不可预测的俚语。| |captureng|[https://github.com/ecological-codes/captureng](https://github.com/ecological-codes/captureng)|*会话知识捕获：* 专注于捕获智能体会话并创建检查点。从生态角度看，这防止了“幻觉漂移”与上下文丢失。通过允许智能体可靠保存与恢复其状态，它们可持续运行而无需不断重新处理初始指令。| |packageng|[https://github.com/ecological-codes/packageng](https://github.com/ecological-codes/packageng)|*技能验证：* 负责打包与严格验证 `.skill` 文件。这充当生态系统的“免疫系统”。在将新能力部署至智能体之前，必须验证代码结构健全并符合整体安全格式与协议。| |safe-skill-creator|[https://github.com/ecological-codes/safe-skill-creator](https://github.com/ecological-codes/safe-skill-creator)|*迭代安全设计：* 用于设计与迭代新技能的工具。并非让智能体无约束地编写代码，而是在受约束的环境中让新智能体能力“天生安全”且自诞生起就与生态代码对齐。| ## 5. 生态化与非生态化设计的对比分析 基于上述工具与概念，我们可以评估生态化设计相对于传统非生态化用户提示的效用与“优良质量”。 ### 5.1. 什么是“非生态化”设计？ 非生态化方法依赖临时性的、俚语化的用户提示与边界模糊的 AI 模型交互。它将智能体视为对话式神谕，而非更广泛计算环境的结构化组件。它缺乏严格的内存管理，依赖隐式的安全训练而非明确的系统性公理，并使用未经验证的结构化“工具”。 ### 5.2. 效用与优良质量对比 #### A. 结构效用：确定性 vs. 灵活性 - **非生态化：** 灵活性高但确定性低。用户可将任意内容作为输入，智能体尝试解释。但输出脆弱，在自动化无人值守的工作流中容易出错。 - **生态化（prompteng 与 packageng）：** 初始灵活性较低但确定性高。由于提示被严格结构化，且技能必须通过 `.skill` 包验证后才可使用，智能体行为可预测。 **优良质量：** 对于复杂的多智能体编排，生态化设计显著更优。它将提示工程视为与软件工程一样的正式学科，而非业余的创造性写作。 #### B. 安全性与边界控制：免疫 vs. 脆弱 - **非生态化：** 极易受到提示注入、越狱与供应链攻击。如果用户指示智能体获取恶意脚本，智能体很可能执行，除非基础模型的内部防护机制拦截。 - **生态化（user-prefs 与 trusted-hosts）：** 基于“零信任”基准。系统提示几乎绝对优先于用户提示，且通过出口允许列表（`trusted-hosts.md`）等机制提供硬边界。生态健全的智能体不应能从未经授权的来源拉取数据。 **优良质量：** 生态化设计将安全负担从不可预测的用户提示转移到不可否认的系统提示，显著缩小攻击面。 #### C. 状态可持续性：内存卫生 vs. 上下文崩溃 - **非生态化：** 依赖滑动上下文窗口。在长会话中，智能体最终会遭遇“上下文崩溃”——遗忘初始指令、产生幻觉或耗尽令牌限制。这在长期任务中本质上不可持续。 - **生态化（captureng）：** 专注于“内存卫生”与主动状态捕获。通过从会话中派生检查点并谨慎管理保留在上下文中的数据，智能体可在不退化的情况下无限运行。 **优良质量：** 在生态学意义上，非生态化智能体最终会因过多令牌“污染”自身环境直至崩溃。而生态化智能体自行清理，维持持续自治运行的高度可持续性。 #### D. 状态感知：持续耦合 vs. 事务性提示 - **非生态化：** 事务性且离散。AI 在用户输入前存在于真空中；“无提示”即“无操作”。模型暂停等待，对沉默期间的时间流逝或环境状态毫无感知。 - **生态化（基于代码 0）：** 关系性且持续。智能体与环境“生态耦合”，因此输入的绝对缺失是不可能的。提示缺失、网络请求失败或编排器无响应会被主动解释为有效信号（例如超时、空闲状态或通信链路中断）。 **优良质量：** 这使得智能体具备环境感知能力与弹性。智能体不会在编排器停止心跳时无限挂起或静默失败，而是能优雅地利用“信号缺失”作为触发器，启动安全协议、后台任务或状态保存流程。 ## 6. 关于效用的结论 生态代码中的“优良质量”体现在从拟人化交互（将 AI 当作人类交谈）到系统集成（将合成智能体与生物用户视为网络生态中持续耦合、严格监管的节点）的转变。尽管非生态化提示对普通用户更易上手，但生态化设计提供了企业级智能体所需的卫生、边界、弹性与可靠性。 *等等，我说的是企业级智能体吗？我指的是星际工业级的不朽自治智能体！[LOLs](https://en.wikipedia.org/wiki/WALL-E_(character)#/media/File:WALL-E_(character).png)。* ## 许可证 参见 [LICENSE](./LICENSE.txt) 进行中（WIP）。

标签：SEO: 代理规范, SEO: 生态代码, 代理系统, 伦理AI, 信号理论, 信息论, 可解释性, 多智能体, 多模态安全, 开源, 技术标准, 技术栈: 提示工程, 技术栈: 规则引擎, 数据可视化, 生态计算, 规范协议, 跨域通信, 防御加固, 领域耦合