源码级拆解大模型看图与执行命令机制，GeminiCLI揭示Agent工作真相

大模型能否“看图”、能否“执行命令”，是用户最常提出的疑问。答案并非模型本身具备视觉或操作系统权限，而是依赖一套精密的工具调用与反馈循环机制。近期，开发者对 Google 官方开源的终端 AI 编程助手 gemini-cli（v0.69.0-nightly，2026-11 快照）进行源码级剖析，清晰还原了这一过程的技术实现路径。

该流程可类比为一位被关在纯文本房间中的“天才”：他知识渊博却无眼无手，仅能收发纸条。用户需提前提供一份“工具菜单”，如 read_file、run_shell_command 等服务及其参数规范；当模型需要查看图片或运行测试时，它仅在纸条上写下 JSON 格式的函数调用请求，例如 {"name": "read_file", "args": {"path": "cat.png"}}；由 gemini-cli 程序作为“服务员”代为执行，并将结果以 functionResponse 形式写回新纸条；模型读取后继续生成下一步指令，直至最终输出结论并标记任务完成。

模型无法直接访问文件系统，但它能根据上下文推理出应调用 read_file 并传入正确路径；执行结果经封装后返回，模型再据此生成后续指令。整个过程构成一个典型的 Agent 循环：感知（接收响应）→ 决策（生成新指令）→ 行动（调用工具）→ 反馈（接收结果）。

值得注意的是，图像处理同样遵循此范式。当用户上传 cat.png，gemini-cli 会将其 base64 编码嵌入 inlineData 字段传入模型；模型若需识别内容，会调用如 vision_analyze 工具（非默认内置，需额外注册），该工具内部可能调用本地多模态模型或调用云 API，最终返回文本描述。这解释了为何“看图”能力并非模型原生具备，而是依赖工具链的扩展。

这一机制的底层前提，是大模型本身仅具备语言建模能力。正如补充资料所述，一个下载下来的 70 亿参数模型文件，本质是一组随机初始化的浮点数，未经训练前不具备任何语义理解能力。其能力来源于三阶段加工：预训练（学习语言统计规律）、SFT（监督微调，学会问答格式）、强化学习（对齐人类偏好）。其中，预训练决定了模型的“能力上限”，而后训练则决定该上限能否被有效调用——而工具调用正是后训练阶段的关键延伸。

在 gemini-cli 中，工具注册发生在每次请求前：

这意味着工具集可动态配置，不同场景下可加载不同能力模块。例如，在开发环境中启用 run_shell_command、write_file；在设计协作场景中接入 codesign-mcp-server（如补充素材提及的腾讯 CoDesign 设计稿解析服务），使模型能“读懂”设计稿结构并生成前端代码。

这种架构带来显著优势：安全性高（模型无直接系统权限）、可扩展性强（新增工具无需重训模型）、调试友好（每一步调用与响应均可记录）。但同时也存在局限：依赖工具实现质量；若工具返回错误或延迟，模型易陷入无效循环；对复杂任务的规划能力仍受限于模型自身推理深度。

行业实践已广泛采用类似模式。OpenAI 的 Function Calling、Anthropic 的 Tool Use、Google 的 Gemini Tools 均基于相同原理。国内如 DeepSeek-V3 在后训练阶段大幅压缩成本（预训练占 2664K GPU 小时，后训练仅 5K 小时，占比 0.18%），正说明提升工具调用效率与可靠性已成为当前技术竞争焦点。

随着 MCP（Model Control Protocol）等标准化协议推进，工具调用正从各厂商私有实现走向统一接口。未来，模型将更像一个“智能调度员”，专注于任务分解与决策，而具体执行交由专业化工具链完成。这既降低了模型部署门槛，也推动了 AI 应用向模块化、可组合方向演进。

源码层面的透明化，使得开发者能真正理解 Agent 的运作边界与潜力。gemini-cli 作为开源参考实现，不仅验证了“模型即文本处理器”的朴素原理，也为构建可靠、可控的 AI 助手提供了工程范本。