面试题库

分析过程 · 先想清楚再作答

1. 先把问题拆成两半：计费是「记录问题」，工具副作用是「执行问题」，两者的解法不同，混在一起答会含糊。
2. 计费侧：用量应该在服务端按实际收到的 token 记账，而不是按「请求次数」。断在中途已经产生的 token 是真实成本，要照记；重试产生的是新成本，也要照记——关键是别把同一批 token 记两遍。
3. 为此需要一个稳定的标识：给每轮生成一个 run id，用量记录以 run id + 序号去重，重放同一段不会重复入账。
4. 工具侧：真正危险的是有副作用的工具（转账、发消息、下单）。解法是幂等键——由调用参数派生一个稳定的 key，执行前先查这个 key 是否已有结果，有就直接返回旧结果。
5. 补一层状态机视角：把每次工具调用记为「待执行 / 执行中 / 已完成」，重试时只重放未完成的部分，已完成的直接取结果，这也是恢复中断任务的通用做法。
6. 常见追问：幂等键该谁生成？应由客户端或调度侧生成并随请求传递，服务端自己生成就没法跨重试保持一致。

How to reason about it · think before answering

1. Split it in two: billing is a bookkeeping problem, tool side effects are an execution problem, and they have different fixes.
2. Billing: meter server-side by tokens actually produced, not by request count. Tokens produced before the break are real cost; so are retry tokens. The point is not to count the same batch twice.
3. That needs a stable identifier: give each generation a run id and dedupe usage records by run id plus sequence.
4. Tools: the danger is side-effecting tools — transfers, messages, orders. The fix is an idempotency key derived from the call arguments, checked before execution.
5. Add the state-machine view: record each call as pending / running / done and replay only what is unfinished.
6. Follow-up: who generates the idempotency key? The caller must, and pass it along — a server-generated key cannot stay stable across retries.

分析过程 · 先想清楚再作答

1. 题眼有两个：一是「谁来执行」，二是「副作用有多大」。只答功能对比不谈执行方与风险，就是没做过工程。
2. 先给执行方的判据：内置工具由平台在服务端执行，你只声明、不回填、也控制不了它怎么搜；函数工具由你执行，样样自己写，但每一步都在你手里。
3. 落到场景：数据在外面且通用（公网、你上传的文档）用内置工具；数据在你系统里（数据库、内部服务、业务逻辑）写函数；生产系统几乎总是混用。
4. 再按副作用排一条光谱：web search 只读公网，file search 只读你给的文件，函数调用的副作用由你的代码决定，computer use 由模型直接产生副作用——越往右能力越强，需要的隔离越重。
5. computer use 单独对待的原因：它能点任何按钮、输任何文字，还可能被页面内容诱导，所以正确起点是隔离环境、受限账号和站点与动作白名单，不是代码。
6. 可预期的追问：内置的 file search 和自己搭 RAG 怎么选？前者是托管版，省掉切分、向量化、检索三步，代价是可控性与可观测性弱，需要自定义切分或重排时才自己搭。

How to reason about it · think before answering

1. Two cruxes: who executes the tool, and how large its side effects are; comparing features alone signals no production experience.
2. Executor test: built-in tools run server-side, you declare but never fill results and cannot steer the search; function tools run in your code, more work but full control.
3. Map to scenarios: external, generic data (the web, your uploaded documents) fits built-ins; data inside your systems (databases, internal services, business logic) needs functions; production mixes both.
4. Order by side effects: web search reads the public web, file search reads your files, function calls have whatever side effects your code allows, computer use lets the model act directly; more capability demands heavier isolation.
5. Computer use is special because it can click anything, type anything and be steered by on-screen content, so the starting point is an isolated environment, a restricted account and an allow-list, not code.
6. Expect the follow-up: built-in file search versus your own RAG? The built-in is a managed pipeline that skips chunking, embedding and retrieval work at the cost of control and observability; build your own when you need custom chunking or reranking.