Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D5 The Tool System and Event-Driven Design: Parameter Validation, Feeding Errors Back for Self-Correction, Event Subscription (dg P05/P06/M05/M07)

• What principles do you follow when designing tools for an agent — how do you write the name, the description and the parameter schema?设计 Agent 的工具时你会遵循哪些原则？名字、描述、参数分别该怎么写？

  Common in ChinaCommon overseasBasic#tool-design#prompt-engineering

  How to reason about it · think before answering

  1. The discriminator is what you think a tool description is. People who treat it as a docstring answer 'describe what it does'; people who treat it as part of the prompt get it right — the description goes verbatim into the model's context and drives both tool selection and argument filling. Its reader is the model, not your teammate.
  2. Split it into three: names read like commands (query_order, not handler2) because the name is the model's first filter; the most valuable sentence in a description is not what the tool does but when NOT to use it, which removes most misrouting; and every parameter needs its own description plus a concrete example for format-shaped fields — a model has no notion of 'order id', but SO20260901 makes it far more likely to get it right.
  3. Then raise the cost point most candidates miss: tool definitions are resent in full every turn. A well-written tool runs 100 to 150 tokens, so twenty of them is a fixed two- to three-thousand-token tax per turn. More tools is not more capable — only mount what the current scenario needs.
  4. Add a transferable engineering judgment: renaming a tool or silently widening its semantics is a breaking change. Tuned prompts stop working, and old sessions still carry the old name in messages, so resuming one makes the model call a tool that no longer exists. Version and roll out tool changes the way you would a public API.
  5. Expect the follow-up: what about dozens or hundreds of tools? Retrieve tools with a cheap model first and mount only the top few, rather than shipping the whole catalog every turn.

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

  1. 这题的区分度在于你把工具描述当成什么。当成函数注释的人会答「写清楚做什么」，当成提示词的人才会答到点子上——描述会原样进入模型的上下文，参与「该不该调、参数填什么」的判断，它的读者是模型不是同事。
  2. 拆成三件事分别说：名字要动词加宾语（query_order 而不是 handler2），因为名字是模型的第一道筛选；描述最有价值的一句不是「做什么」而是「什么时候不该用它」，把边界写进去能砍掉一大半误用；参数里每个字段都要有自己的 description，格式类字段还要给一个合法示例——模型对「订单号」没有概念，看到 SO20260901 这个样例，填对的概率会陡增。
  3. 接着给出一条几乎没人主动说的成本判断：工具定义每一轮都会被完整重发，一个写得扎实的工具约 100 到 150 token，挂 20 个就是每轮两三千 token 的固定开销。所以「工具越多越强」是错的，只挂当前场景用得上的那几个。
  4. 再补一条可迁移的工程判断：工具改名或改语义是破坏性变更，等价于换了个工具——调好的提示词会失效，历史会话的 messages 里还留着旧名字，恢复旧会话时模型会去调一个不存在的工具。所以改工具要像改公开 API 一样走版本与灰度。
  5. 可以预期的追问：几十上百个工具怎么办？答案是先用一轮便宜模型做工具检索，只把最相关的几个塞进正式请求，而不是一股脑全挂上。

  Key points

  • A tool definition is part of the prompt; the model only sees name, description and parameter schema
  • Name it verb plus object; the most valuable line in a description is when not to use it; every parameter needs a description, and format fields need a concrete example
  • Definitions are resent every turn, so twenty tools is a fixed two- to three-thousand-token tax — mount only what the scenario needs
  • Renaming or redefining a tool is a breaking change that invalidates tuned prompts and breaks resumed sessions
  • At scale, retrieve the relevant tools with a cheap model before mounting them

  答题要点

  • 工具定义是提示词的一部分，读者是模型：它只能看到名字、描述、参数 schema，看不到你的实现
  • 名字用动词加宾语；描述里最值钱的是「什么时候不该用它」；每个参数都要有 description，格式类字段给一个合法示例
  • 工具定义每轮完整重发，20 个工具就是每轮固定两千多 token，只挂当前场景用得上的
  • 改名或改语义等于换工具，会让调好的提示词失效、让旧会话调到不存在的工具，要走版本与灰度
  • 工具规模上去之后，先用便宜模型做工具检索再挂载最相关的几个

D12 Long-Term Memory: pgvector, Embeddings, Chunking, the memory_search Tool

• What matters when designing the parameters of a retrieval tool such as memory_search?把记忆检索包装成 memory_search 这样的工具时，参数设计上要注意什么？

  Common in ChinaCommon overseasDeep dive#tool-design#security#long-term-memory

  How to reason about it · think before answering

  1. It looks like an API design question; the discriminating part is security. Most candidates name query and limit and stop. Saying which parameters must never be exposed to the model is what earns the point.
  2. On query: the description must state that it is a retrieval phrase the model composes, not the user's literal words, and give a concrete example. Asked 'what are my dietary restrictions', the model should search for 'the user's food allergies and restrictions'.
  3. On limit: optional, default 5, capped at 10. The cap is a context budget, not idiot-proofing — a memory is roughly 400 tokens, so ten of them put 4000 tokens into the request. When the model asks for 50, return a readable validation error naming the field, the valid range and an example, rather than silently clamping, or it never learns it was wrong.
  4. The critical rule: never expose an identity parameter such as user_id. Identity comes from the session. Making it a parameter hands 'whose memories to read' to probabilistically generated text, and one prompt injection turns it into a privilege-escalation read. Prompts govern intent; code governs permission.
  5. Cover the response shape too: an empty result must say so explicitly and forbid guessing, because an empty string reads to the model as 'no constraints' and invites fabrication; return similarity scores so the model can distinguish a firm memory from a vague one; and set a minimum score, since no result beats a noisy one.
  6. Expect: what should happen on a miss? Two layers — the tool returns empty honestly and forbids speculation, and the prompt instructs the model to ask the user instead of treating 'not found' as 'no preference'.

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

  1. 这题看着是接口设计题，真正的区分度在安全。多数人会答 query 和 limit，答完就停；能不能说出「哪些参数绝对不能给模型」，决定了这题的分数。
  2. 先说 query：描述里要写清它不是用户原话，而是模型自己组织的检索语句，并给一个合法示例。用户问「我有什么忌口」，模型应该用「用户的食物忌口」去检索——这是从 D5 那条「格式类字段要给合法示例」延续下来的。
  3. 再说 limit：可选、默认 5、上限 10。上限的理由不是防呆，是上下文预算——一条记忆约 400 token，10 条就是 4000 token 进请求。模型传 50 时按工具协议回一条可读错误让它改，而不是静默截断成 10，否则模型永远不知道自己传错了。
  4. 然后是关键的一条：**绝不给 user_id 这类身份参数**。用户身份只能来自会话上下文。做成参数等于把「查谁的记忆」交给一段概率生成的文本，配上一句提示词注入就是现成的越权读取漏洞。一句话收尾：提示词管意图，代码管权限。
  5. 返回格式同样要说：空结果必须显式返回一句「没有找到相关记忆，请不要凭空推测」，返回空串模型会当成没有约束然后自己编；把相似度分数一起返回，模型才能区分「你说过」和「我印象里你好像提过」；设一条相似度下限，宁可不返回也不要拿噪声污染上下文。
  6. 可以预期的追问：检索不到的时候该怎么办？答案是分两层——工具层如实返回空并禁止推测，提示词层要求模型转而向用户确认，而不是把「没检索到」当成「用户没有偏好」。

  Key points

  • query is required; document it as a model-composed retrieval phrase, not the user's literal words, with an example
  • limit is optional, defaults to 5 and caps at 10 on context-budget grounds; over the cap, return a readable validation error instead of silently clamping
  • Never expose user_id or any identity parameter — identity comes from the session, or prompt injection becomes a privilege-escalation read
  • An empty result must say so explicitly and forbid speculation, or the model fabricates
  • Return similarity scores and enforce a minimum, since no result beats a noisy one

  答题要点

  • query 必填，描述里说明它是模型组织的检索语句而非用户原话，并给一个合法示例
  • limit 可选、默认 5、上限 10，上限的依据是上下文预算；超限按工具协议回可读错误让模型改，不要静默截断
  • 绝不把 user_id 这类身份参数交给模型，身份只能来自会话——否则一句提示词注入就是越权读取
  • 空结果要显式说「没找到，请不要凭空推测」，返回空串模型会自己编
  • 返回相似度分数并设下限，宁可不返回也不要用低相关记忆污染上下文