Interview Bank

How to reason about it · think before answering

1. The second half is an open trap. 'Add a counter' is the passing grade; what they want is whether you know what a counter cannot catch.
2. Explain why it runs away first: the finish reason stays tool_calls because the tool results are not moving the model forward — empty results, fields that do not answer the question, error text that never says what correct looks like. So the first line of defense is not a guard rail at all; it is writing tool results and error messages that carry information.
3. Then three complementary hard limits: a step cap is the obvious one; a token and cost budget catches 'few steps, all of them expensive'; a per-step wall-clock timeout catches 'one call hung for two minutes'. A system with only a step cap can still blow its budget on a single enormous context.
4. Add a semantic guard: detect repeats. The same tool with identical arguments twice in a row is almost always spinning. Cut it short and tell the model so — 'you already called this tool with exactly these arguments' — which usually converges faster than waiting for the counter to run out.
5. Hitting the cap needs an honest ending: never return an empty string, give the user a sentence they can act on, and record cap hits as a metric. A rising cap-hit rate usually means a tool's description or return value needs fixing, not that the cap should be raised.
6. Expect: what number do you pick? There is no universal one. Chat-style tasks usually fit in five to ten steps; retrieval-heavy tasks need more. Read the production distribution, take p99 plus headroom, and remember that the tighter the cap, the closer your system sits to a fixed workflow rather than an agent.

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

1. 后半句是明摆着的陷阱。只答「加一个计数器」是及格线，面试官真正想听的是你知道计数器拦不住什么。
2. 先解释它为什么会停不下来：停止原因一直是 tool_calls，通常是因为工具返回的东西没帮模型前进——结果为空、字段答非所问、错误文案没说清该怎么改，于是它换个参数一试再试。所以第一层其实不是护栏，是把工具的返回值和错误文案写得有信息量。
3. 再给硬护栏，三条互补：步数上限最直接；token 与成本预算拦的是「步数不多但每步都很贵」；单轮的墙上时钟超时拦的是「一步就卡了两分钟」。只有步数上限的系统，照样会被一次超长上下文的调用打爆预算。
4. 语义层面再加一条：检测重复调用。同一个工具、同一份参数连续出现两次以上，几乎可以断定它在原地打转，直接截断并把「你已经用完全相同的参数调过这个工具了，换个思路或者告诉用户你做不到」回传给模型，往往比等步数耗尽更快收敛。
5. 触顶之后必须有交代：不能静默返回空字符串，要给用户一句能理解的话；同时把触顶记成一个指标，触顶率上升通常意味着某个工具的描述或返回值该改了，而不是把上限调大。
6. 可以预期的追问：上限设多少？没有普适值。聊天类任务 5 到 10 步通常够，需要多轮检索的任务可以更高。正确做法是看线上的步数分布，取 p99 再留一点余量，而不是拍脑袋——上限设得越死，你的系统就越靠近固定流程那一端，越不像一个 Agent。

How to reason about it · think before answering

1. This screens whether you have ever made such a loop actually terminate. Answering only set a max round count scores nothing — that prevents an infinite loop, it is not convergence design. The signal is naming three exits plus how the reviewer itself is built.
2. Start with the reviewer: it should not be one model but two layers. Machine-checkable defects (missing fields, out-of-range numbers, length limits, invalid references) go to code; only the judgment calls go to the model. This decides score stability — a pure-model reviewer can swing by ten-plus points on the same draft, and then convergence is meaningless.
3. Then the three exits: stop on threshold (the threshold means good enough, not perfect — chasing the last few points costs far more than it returns); stop at the round cap, handing back the highest-scoring draft rather than the last one, because review scores fluctuate; and escalate to a human once only judgment-call issues remain, since a model reviewing and revising itself just circles.
4. Also cover the scoring weights: hard defects should dominate, say seventy percent, with the model's soft score at thirty. Otherwise one flattering model review outweighs five real field errors and the loop declares success on round one.
5. Conclusion and cost: all three exits need parameters, and parameters need empirical tuning. Too high a threshold burns every round; too low ships an unusable draft. Plot the score curve before shipping and confirm it rises monotonically.
6. Likely follow-up: how do you know it is improving rather than oscillating? Track the hard-defect count — it is deterministic, while the score jitters. If hard defects do not fall, the writer is not acting on feedback, and the fix is feedback granularity: tag each issue with a category so the model knows which class to repair.

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

1. 这题在考「你有没有让这种循环真的停下来过」。只答「设一个最大轮数」拿不到分，那只是防死循环，不是收敛设计。区分度在于你能不能说出三个出口以及评审本身该怎么构造。
2. 先拆评审：评审不该是一个模型，而是两层——能被程序判定的硬伤用代码查（字段缺失、数值越界、长度超限、引用不合法），程序判不了的软伤才交给模型。这一步决定了分数稳不稳定：全交给模型，同一份稿子两次评分能差十几分，循环就没有收敛可言。
3. 再说三个出口：达标就停（阈值是「够用」不是「完美」，追最后几分成本远高于收益）；到轮数上限就停，而且要交出历史最高分那一稿而不是最后一稿，因为评审有波动；剩下的问题全是软伤时转人工，因为让模型自己评自己改只会原地打转。
4. 还要说计分方式：硬伤应该占大头（比如七成），软分占小头。否则模型一句好评就能盖过五条实打实的字段问题，循环会在第一轮就假装达标。
5. 结论加代价：三个出口都需要参数，而参数必须实测调。阈值高了轮数用满，低了稿子不能看；上限大了烧钱，小了永远差一口气。上线前要把分数曲线画出来看它是不是单调上升。
6. 可预期的追问：怎么知道循环真的在变好而不是在抖动？看硬伤条数，它是确定性的；分数会抖，硬伤条数不会。硬伤降不下去就说明写手根本没在按意见改，问题出在意见的粒度上——意见要带分类标签，模型才知道该改哪一类。