OpenCode 对接实践：从独立进程到共享 Runtime 的架构演进
💡
原文中文，约7000字，阅读约需17分钟。
📝
内容提要
本文分享了HagiCode集成OpenCode AI助手的实践经验，重点介绍了架构演进、设计决策及遇到的问题。最初采用独立进程模式，但因资源开销大，最终改为共享runtime模式，显著提升了性能。总结了会话管理、错误恢复机制等关键设计，为后续项目提供参考。
🎯
关键要点
- HagiCode 集成 OpenCode AI 助手的实践经验分享，重点在于架构演进和设计决策。
- 最初采用独立进程模式，但因资源开销大，最终改为共享 runtime 模式，显著提升了性能。
- 会话管理和错误恢复机制是关键设计，支持会话恢复和自动重试，增强系统健壮性。
- 架构分为五层：仓库集成层、Provider 层、Runtime 管理层、Session 持久化层和错误恢复层。
- 会话绑定策略灵活，支持新会话、恢复会话和重启会话，确保用户体验。
- 关键配置包括启用状态、可执行文件路径、请求超时时间等，确保系统稳定运行。
- 总结经验：资源共享重要、状态管理需谨慎、错误恢复机制不可或缺。
❓
延伸问答
HagiCode 集成 OpenCode 的架构演进经历了哪些关键变化？
HagiCode 最初采用独立进程模式，但因资源开销大，最终改为共享 runtime 模式，显著提升了性能。
在 HagiCode 中，如何管理会话和错误恢复？
HagiCode 通过会话绑定策略支持新会话、恢复会话和重启会话，同时使用自动重试机制提高系统的健壮性。
HagiCode 的架构分为哪几层？
HagiCode 的架构分为五层：仓库集成层、Provider 层、Runtime 管理层、Session 持久化层和错误恢复层。
为什么 HagiCode 最初选择独立进程模式？
独立进程模式提供了良好的隔离性，确保一个进程崩溃不影响其他会话，但实际运行中暴露出资源开销大的问题。
HagiCode 如何解决 400 BadRequest 错误？
HagiCode 通过维护自管 runtime，避免依赖外部端点，从而解决了因缺少上下文信息导致的 400 BadRequest 错误。
在 HagiCode 中，如何配置 OpenCode 的关键参数？
在 appsettings.yml 中配置 OpenCode provider，包括启用状态、可执行文件路径和请求超时时间等关键参数。
➡️
