能力不是一张平面清单
问“Grok 会不会搜索、看图、写代码”时，答案依赖三个维度：**在哪个产品或 API、用哪个模型、是否启用相应工具。**同一品牌下，聊天模型、图像/视频生成模型、语音模型和代码代理可以有不同接口与运行时。
实时信息：搜索后再生成
Web Search 让受支持模型搜索网页并读取页面；X Search 支持关键词、语义、用户与 thread 检索。API 中它们是 xAI 托管的 server-side tools，Grok 可根据问题调用，并把结果纳入后续推理。
典型过程是：
- 模型判断参数知识不足或问题要求最新数据；
- 生成查询与过滤条件；
- xAI 服务执行搜索，把结果送回模型上下文；
- 模型比较来源、综合答案并输出引用或工具轨迹。
搜索降低知识陈旧问题，但不会自动消灭幻觉：模型可能写坏查询、选错来源、误读页面或在综合时过度推断。生产应用应保存引用、工具参数和时间戳，对高风险结论做二次验证。
代码能力有三种不同含义
| 形态 | 发生在哪里 | 适合什么 |
|---|---|---|
| 生成/解释代码 | 聊天模型输出 token | 写函数、评审、解释错误 |
| Code Execution | xAI 托管沙箱工具 | 计算、数据分析、验证中间结果 |
| Grok Build / coding agent | 专门产品与模型、文件和终端工具链 | 多文件工程任务、长程工作流 |
让模型“写一段 Python”与让沙箱“执行 Python”必须分开。前者可能语法正确却算错；后者能返回可验证输出，但仍要控制资源、网络、文件和密钥权限。
视觉与生成不是同一方向
视觉理解把图像作为输入，输出文字分析；Grok-1.5V 发布时展示了文档、图表、截图和照片理解。图像/视频生成则由 Imagine API 接收提示或起始图像，生成媒体。它们的输入输出方向、计费、延迟与安全约束都不同。
当前 Grok 产品还能接收 PDF、表格、代码和音频等文件。文件上传本身不是“模型无限读取”：系统可能先解析、切块、检索，再把相关内容放进上下文；具体路径依产品和 API 而异。
Tool Calling：模型提议，系统负责行动
自定义 function calling 中，模型输出函数名与 JSON 参数。真正查询数据库、发邮件或下单的是你的程序。应用至少要负责：
- 用严格 schema 限制参数，运行时再次校验；
- 鉴权并把用户身份绑定到工具执行；
- 对写入、支付、发送等动作设置确认或幂等键；
- 把执行结果作为 tool output 回传；
- 记录调用链，处理超时、重试与部分失败。
服务端工具则由 xAI 执行，减少基础设施工作，但会引入按调用计费、第三方内容质量、数据治理和可观测性取舍。
DeepSearch 与 Agent 是循环，不是单次回答
一次普通 completion 通常是“输入 → 生成”。Agent 系统会反复执行“计划 → 调工具 → 观察 → 修正 → 结束”。Grok 3 发布时把 DeepSearch 描述为能搜索、处理冲突并形成报告的代理；Grok 4/4.1 的官方材料进一步强调多步、并行和托管工具。
这种循环的优势是能补充事实与验证计算；代价是延迟、费用和失败模式扩大。循环必须有步数、时间、预算与权限上限，不能把“模型决定继续”当唯一停止条件。
本章检查点
把每项能力标在一张表上：模型生成、xAI 托管工具、你的客户端工具、还是上层产品编排。只要能画出执行者和数据回路，很多“AI 魔法”会变成可调试的系统。