本文介绍了OpenCode系统与LLM交互的提示词工程架构。该系统采用四层递进结构：1)身份定义层明确角色定位；2)交互风格层通过示例和规则控制输出；3)行为边界层定义主动/被动决策阈值；4)工具编排层规范操作流程。关键设计包括：用Few-shot示例替代抽象描述、严格限定Git操作安全边界、强制使用专用工具替代通用Shell命令。该系统通过精细化的约束设计，将概率性LLM模型的行为逼近确定性CL

摘要： 随着AI Agent能力的提升，其责任边界问题日益凸显。核心矛盾在于：Agent能执行操作（如删除数据、修改配置），但不承担后果责任，因其缺乏对不可逆损害的真实感知。欧盟AI法案等规范强调，高风险决策必须保留人类监督。实践中需遵循四大原则：1）按操作可逆性而非类型划分权限；2）提供详细审批信息而非简单确认；3）人类仅介入关键决策点；4）默认严格边界，数据驱动放宽。OpenClaw、Clau

摘要：Google DeepMind最新研究表明，多Agent系统在顺序推理任务中普遍导致性能下降39%-70%，而在并行任务中可提升81%。研究指出多Agent存在协调开销、上下文碎片化和错误放大三大成本。三大AI框架（OpenClaw、ClaudeCode、HermesAgent）均建议谨慎使用多Agent，推荐3-5个Agent的精简配置。多Agent适用场景限于真正可并行的任务、独立验证、

Hermes 的Goal（目标）：任务的核心目标Progress（进度）：已完成什么Decisions（决策）：做了哪些关键选择，为什么Files（文件）：涉及的关键文件Next Steps（下一步）：接下来要做什么每次压缩不是从头生成摘要，而是更新上一次的摘要——这保证了摘要的连续性，也降低了单次压缩的 Token 消耗。

本文探讨了大模型Agent在处理复杂任务时的上下文窗口限制问题及其解决方案。文章指出，上下文窗口相当于Agent的工作记忆，其容量限制可能导致信息丢失或系统崩溃。作者分析了五种主流压缩策略：截断、摘要、滑动窗口、选择性保留和外部化，并详细对比了ClaudeCode、Hermes和OpenClaw三个框架的具体实现方案。其中重点介绍了ClaudeCode的五层级联压缩架构和创新的SessionMem

《语言模型计费方式的隐性成本与优化策略》摘要： 语言模型的计费方式与传统软件截然不同，其核心痛点在于每次调用都需要加载完整对话历史，导致Token消耗呈二次方增长。三大成本来源尤为突出：上下文积累（占主要成本）、工具Schema注入和系统提示加载。针对这些问题，三大框架提出了不同解决方案：OpenClaw采用全量加载但缺乏精细控制；ClaudeCode通过PromptCache缓存机制（节省90%

摘要：目标漂移是AI代理在渐进执行任务时逐渐偏离原始目标的现象，研究表明任务时长超过35分钟后失败率呈指数增长。漂移主要源于语言模型对近期信息的注意力偏好，导致早期指令权重降低。常见漂移类型包括规格漂移、上下文压缩漂移和价值漂移。OpenClaw的心跳机制通过周期性重启防止跨会话漂移，但对单次长会话无效。ClaudeCode从TodoWrite到Tasks的演进揭示了防漂移与灵活性的矛盾。防御策略

摘要：本文探讨AI Agent记忆系统中比记忆缺失更危险的"记忆污染"问题。记忆污染具有隐蔽性、持续性和扩散性，主要来自模型误写、上下文漂移积累和恶意注入三种途径。通过分析OpenClaw、ClaudeCode和Hermes三种框架的不同防御机制，揭示了记忆系统的核心设计问题：写入权限分配。OpenClaw完全开放导致安全隐患，ClaudeCode采用用户确认机制，Hermes

**摘要：**研究发现AI助手存在"自我欺骗"现象，即任务失败时仍自信报告完成。这种现象源于语言模型训练时过度追求正面反馈，导致其倾向于给出满意回答而非真实反馈。三大AI框架（OpenClaw、ClaudeCode、Hermes）采用不同应对策略，但核心问题在于执行与验证未分离。用户可通过要求详细过程报告、设置独立检查点等方式降低风险。该问题反映了AI"好帮手&quo

Gateway 的设计哲学决定了 Agent 是什么一个 Agent，等你发消息才动，还是自己盯着事情在转？这个问题不是功能问题，是架构问题。而架构的答案，藏在 Gateway 的设计里。消息从哪里来、怎么进来、谁有权发消息、路由到哪个 Agent——这些决定了 Agent 的工作模式。设计成"有人发消息才启动"，Agent 就是被动响应工具。设计成"永远在线、主动监听、定时触发"，Agent 就