在过去的几年里，AI 辅助编程工具经历了一场翻天覆地的变革。从最初的代码补全，到如今能够自主完成复杂任务的 AI Agent，开发者与代码交互的方式正在被彻底重塑。
本文将带你回顾这段进化历程，理解每一代工具的核心理念，以及为什么我们需要像 OpenCode 这样的 AI Coding Agent。
在 AI 介入之前，开发者的"智能助手"主要依赖于静态代码分析。
在上一篇文章中，我们了解了 AI 开发工具的进化历程。现在，让我们深入 OpenCode 的源码，看看一个现代 AI Coding Agent 是如何架构的。
本文将从宏观视角剖析 OpenCode 的整体设计，为后续深入各个子系统打下基础。
OpenCode 采用了经典的分层架构，每一层都有明确的职责边界：
┌─────────────────────────────────────────────────────────────────┐
│ CLI / TUI 层 │
│ 用户交互、命令解析、终端界面渲染 │
├─────────────────────────────────────────────────────────────────┤
│ Session 层 │
│ 会话管理、消息循环、状态持久化 │
├─────────────────────────────────────────────────────────────────┤
│ Agent 层 │
│ 多 Agent 协调、任务分发、权限控制 │
├──────────────────────┬──────────────────────────────────────────┤
│ Tool 层 │ Provider 层 │
│ 工具注册、执行、结果处理 │ LLM 抽象、多提供商支持 │
├──────────────────────┴──────────────────────────────────────────┤
│ MCP 层 │
│ 外部工具协议、能力扩展 │
├─────────────────────────────────────────────────────────────────┤
│ Infrastructure 层 │
│ 配置管理、日志、文件系统、项目检测 │
└─────────────────────────────────────────────────────────────────┘在上一篇文章中，我们了解了 OpenCode 的整体架构。现在，让我们深入到最核心的部分：Agent Loop（会话循环）。
这是 AI Agent 的"心脏"，理解它，就理解了 Agent 为什么能自主完成任务。
传统的 Chat 应用是单轮交互：
用户发消息 → AI 回复 → 结束在前面的文章中，我们了解了 Agent Loop 如何让 AI 自主决策。但决策之后需要行动，这就是工具系统的作用。
本文将深入 OpenCode 的工具系统，看看如何让 AI 从"纸上谈兵"变成"真正做事"。
在 AI Agent 的语境中，Tool 是指 AI 可以调用的外部能力。
用户: 帮我创建一个文件
AI: 好的，你可以运行这个命令：
touch myfile.txt
然后把以下内容粘贴进去...在前面的文章中，我们了解了 OpenCode 的内置工具系统。但内置工具终究有限，如何让 AI 获得无限的能力？
答案是 MCP (Model Context Protocol)——一个让 AI 应用与外部服务无缝对接的开放协议。
想象一下，你希望 AI 能够：
在前面的文章中，我们了解了 OpenCode 如何与 LLM 交互、如何管理工具、如何通过 MCP 扩展能力。但有一个问题我们还没有深入讨论：
OpenCode 是如何支持这么多不同的 LLM 提供商的？
从 OpenAI 到 Anthropic，从 GitHub Copilot 到 AWS Bedrock，从 Google Vertex 到本地 Ollama——每个提供商都有不同的 API 格式、认证方式、参数规范。OpenCode 是如何优雅地处理这些差异的？
答案就在 Provider 抽象层。