任务清单与自我规划：todo 工具、进度渲染与打转的早期发现

面试题库

• 让模型自己维护任务清单，比在提示词里写计划好在哪？代价是什么？What does letting the model maintain its own task list buy you over writing the plan in the prompt, and what does it cost?

  国内高频海外高频基础#self-planning#tool-design

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

  1. 这题在考「你有没有想过这个功能为什么有效」。答「让它更有条理」是空话，会被追问到底。区分度在于你能不能说出一个机制层面的理由，再主动交出代价。
  2. 怎么拆：先回到一条最基本的事实——**模型没有记忆，它每一轮看到的只有上下文里的那些字。** 所以「计划」如果只存在于它这一轮的推理里，下一轮就等于不存在。清单的作用是把计划**外化成上下文里的一段文字**，于是「我做到哪了」从一个需要回忆的问题变成了一个可以直接读的事实。一句话概括：**外化的状态比隐含的计划稳。**
  3. 为什么不是我们替它拆？因为我们拆的清单和它执行的步骤会对不上。你在开始之前拆三步，它执行到第二步发现根本不是那样——清单成了一份错的地图，而它没有权限改；它只能假装照着走（清单是假的）或者不管清单自己干（清单没用）。让它自己写还多两个好处：**计划变成一次可观测的写操作**（你能在它做错之前看见它打算怎么做），以及**进度有了一个与具体工具无关的度量**（第三题会用到）。
  4. 代价必须主动说，这是这题的分水岭：**每一次更新清单都是一次工具往返。** 一张三条的清单光维护它就可能多花三四轮，而每一轮都要把整个消息数组重发一次。所以这个功能有明确的适用边界——三步以内的活儿不要用清单，加了就是把一件三十秒的事变成五轮往返。反过来两种情况价值最大：步骤之间有依赖且中间会失败（失败要退回上一步，有清单才知道退到哪），以及任务长到会跨过一次上下文压缩（清单用几十个 token 保住了「整件事到哪了」）。
  5. 还要讲一个具体的设计取舍来证明你真做过：**状态只留三种（待做、进行中、已完成）。** 加第四种「阻塞」看着更完备，实际是给模型一个体面的逃跑出口——一条做不下去的任务标成阻塞就能名正言顺地绕过去，而清单上看起来一切正常。只有三种状态时，它做不下去就只能说出来，而说出来你才能帮它。
  6. 可预期的追问：清单要不要落盘？不要。它是这一次任务的工作面，不是事实也不是过程；任务结束就没有意义了，存下来只会让下一次对话看到一份过期的待办，然后先花一轮判断这份待办还算不算数。

  How to reason about it · think before answering

  1. This tests whether you have thought about why the feature works. Answering it makes the model more organized is empty and invites follow-ups until you break. The signal is a mechanism-level reason plus volunteering the cost.
  2. How to break it down: start from the basic fact that the model has no memory — every round it sees only the text in the context. So a plan that exists only inside one round's reasoning does not exist in the next. The list externalizes the plan into context text, turning where am I from something to recall into something to read. In one line: externalized state is more stable than an implied plan.
  3. Why not decompose it ourselves? Because our list and its actual steps diverge. You break the work into three steps up front, it reaches step two and finds reality differs — the list is now a wrong map it has no permission to fix, so it either pretends to follow it (the list is fake) or ignores it (the list is useless). Letting the model write it adds two more benefits: the plan becomes an observable write, so you see the intent before the mistake; and progress gains a tool-agnostic metric, which the third question builds on.
  4. You must volunteer the cost, and that is the dividing line: every list update is a tool round trip. Maintaining a three-item list can cost three or four extra rounds, and each round resends the whole message array. So the feature has a clear boundary — do not use a list for work under three steps, or a thirty-second task becomes five round trips. Conversely, it pays off most when steps have dependencies and can fail mid-way (you need to know which step to fall back to) and when the task is long enough to survive a context compaction, where the list preserves where am I for a few dozen tokens.
  5. Cite a concrete design tradeoff to show you built it: keep only three states — pending, in progress, done. Adding blocked looks more complete but hands the model a respectable escape hatch: a task it cannot finish gets marked blocked and legitimately skipped while the list looks fine. With only three states it has to say it is stuck, and only then can you help.
  6. Likely follow-up: should the list be persisted? No. It is this task's working surface, neither a fact nor a record of process; once the task ends it is meaningless, and persisting it just shows the next conversation a stale to-do list it must first spend a round evaluating.

  答题要点

  • 机制理由：模型没有记忆，清单把计划外化成上下文里可读的一段文字
  • 不该我们替它拆：我们拆的步骤会与它的执行对不上，清单会变成一份它无权修改的错地图
  • 额外收益：规划变成可观测的写操作；进度有了与具体工具无关的度量
  • 代价：每次更新都是一次工具往返，所以三步以内不用清单；依赖多、会失败、会跨压缩的任务价值最大
  • 状态只留三种：第四种「阻塞」是给模型的逃跑出口；清单易失不落盘

  Key points

  • The mechanism: the model has no memory, so the list externalizes the plan into readable context text
  • Do not decompose for it: our steps diverge from its execution, leaving a wrong map it cannot edit
  • Extra upside: planning becomes an observable write, and progress gains a tool-agnostic metric
  • Cost: every update is a round trip, so skip lists under three steps; they pay off on dependent, failure-prone, long tasks
  • Only three states: a fourth blocked state is an escape hatch; the list is ephemeral and not persisted
• 终端里同时有流式文本和固定的进度区域，你怎么管光标与刷新？With streaming text and a fixed progress area in the same terminal, how do you manage the cursor and repaints?

  国内高频海外高频进阶#terminal-rendering#cursor-control

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

  1. 这题很难靠背答案过，因为它的坑只有动手写过才知道。区分度有三层：能不能说清冲突的本质、能不能给出一个可实现的方案、能不能主动讲退化路径。
  2. 怎么拆：先说冲突的本质——**一个终端只有一条光标，而现在有两个东西要用它。** 流式文本一直在往下长，进度区域要待在一个不动的地方。直接把进度打出去，下一片文本就会把它挤上去，几秒之后屏幕上是十几个不同版本的进度。
  3. 第一个决定是**面板放底部，不是顶部**。这一条反直觉但很硬：顶部要算「正文已经滚了多少行」，而正文会自动换行，行数由终端宽度决定——你得知道用户窗口有多宽，还得处理他中途拉窗口。**底部只需要知道面板自己有几行，这是唯一一个你真的知道的数字。**
  4. 方案就是四个动作：画出来（保存光标位置 → 换行 → 画面板，光标停在面板末尾）；擦掉（恢复到保存的位置 → 清掉从这里到屏幕末尾的一切，面板没了而正文那半行还在）；写正文（夹在擦掉与画出来之间）；内容变了就擦掉再画一次。用 DEC 的保存/恢复光标而不是自己数行，是因为它只有一个槽位但你也只需要一个，而且它天然处理了「正文那半行停在第几列」这个你算不出来的问题。
  5. 然后是这题的加分项：**把这一层做成一个包装函数，而不是散在渲染代码里。** 拿一个「写字符串」的函数进来，还一个夹了 hide/show 的函数出去。做对之后渲染层一行都不用改——它完全不知道屏幕下方有块面板。这就是分层的价值，而不是「代码更整洁」这种空话。
  6. 退化路径必须主动说：**非 TTY（管道、CI、别的 Agent 的 shell）没有光标可用，就一个光标控制符都不发**，退化成「内容变了就整块打一遍」。判据是 `isTTY`。把控制符发出去让它变成一串乱码，比不做这个功能更糟——而这正是「验收判据是肉眼看到现象、而不是 exit code」的原因。
  7. 可预期的追问：为什么不用 alt-screen（整屏接管）？因为终端会话的历史就没了，用户翻不回上一个任务的输出；一个 CLI 工具占掉整屏，代价远大于收益。真要做全屏 TUI 才考虑它。

  How to reason about it · think before answering

  1. This one is hard to fake, because its pitfalls only show up once you have written it. There are three levels of signal: naming the real conflict, giving an implementable scheme, and volunteering the degradation path.
  2. How to break it down: the conflict is that a terminal has one cursor and two things now want it. Streaming text keeps growing downward while the progress area must stay put. Print the progress directly and the next chunk pushes it up, so within seconds the screen holds a dozen stale copies.
  3. The first decision is to put the panel at the bottom, not the top. It is counterintuitive but firm: the top requires knowing how many lines the body has scrolled, and the body soft-wraps, so its line count depends on terminal width — you would need the window width and would have to handle the user resizing mid-run. The bottom only requires knowing how many lines the panel itself has, which is the one number you actually know.
  4. The scheme is four actions: draw (save the cursor, newline, paint the panel, leaving the cursor at its end); erase (restore to the saved position, then clear from there to the end of the screen — the panel is gone and the half-written body line survives); write body text (sandwiched between erase and draw); and repaint on change by erasing and drawing again. Use the DEC save/restore cursor rather than counting lines: there is only one slot but you only need one, and it naturally handles which column the half-written line stopped at, a number you cannot compute.
  5. Then the bonus: make this a wrapper function rather than scattering it through render code. Take a write-string function in, hand a hide/show-sandwiched one back. Done right, the render layer needs no changes at all — it never learns there is a panel below. That is what layering buys, as opposed to vague talk about cleaner code.
  6. Volunteer the degradation path: a non-TTY destination (a pipe, CI, another agent's shell) has no usable cursor, so emit no cursor control sequences at all and degrade to reprinting the block whenever it changes. The test is the isTTY flag. Emitting control sequences into a pipe turns them into garbage, which is worse than not having the feature — and it is exactly why acceptance must be a human looking at the screen rather than an exit code.
  7. Likely follow-up: why not use the alternate screen buffer? Because the session scrollback is then gone and the user cannot scroll back to the previous task's output. A CLI taking over the whole screen costs far more than it gains; consider it only for a genuine full-screen TUI.

  答题要点

  • 冲突本质：一个终端一条光标，流式文本往下长而面板要不动
  • 面板放底部：顶部要算正文滚了多少行，而软换行让行数取决于窗口宽度；底部只需知道面板自己几行
  • 四个动作：保存光标画面板、恢复光标清到屏幕末尾、正文夹在中间写、变化时擦掉重画
  • 把 hide/show 做成一个包装函数，渲染层一行都不用改，也不知道面板存在
  • 非 TTY 一个控制符都不发，退化成整块重打；判据是 isTTY，验收靠肉眼看现象

  Key points

  • The conflict: one cursor, with streaming text growing downward and a panel that must stay put
  • Put the panel at the bottom: the top needs the body's scrolled line count, which soft-wrapping makes width-dependent
  • Four actions: save cursor and paint, restore cursor and clear below, write body in between, repaint on change
  • Make hide/show a wrapper function so the render layer needs no changes and never learns the panel exists
  • On a non-TTY emit no control sequences and reprint the block; the test is isTTY, and acceptance is visual
• 怎么从运行数据里发现 Agent 已经在打转？发现之后怎么干预？How do you detect from runtime data that an agent is spinning in place, and what do you do once you detect it?

  国内高频海外高频深入#stall-detection#agent-observability

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

  1. 这题最容易只答一半：「检测重复调用」。那确实是一种打转，但它是最容易抓也最不常见的那一种。区分度在于你能不能说出另一种形态，以及为什么第一种检测抓不到它。
  2. 怎么拆：把打转分成两种形态。**机械重复**——一字不差地反复调同一个工具同一个参数；**原地兜圈**——每一轮都在做不一样的事，但一件都没做完。第一种用「工具名 + 参数原文」当键，连续命中到阈值就打断，实现很朴素；关键是三条口径：比参数原文不比语义（只差一个空格就算在尝试新东西），只看连续（中间插过别的调用就重新计数，因为「读了改了再读一次确认」是正常节奏），以及打断的方式是回灌而不是抬头。
  3. 第二种才是长任务里最常见、也最难发现的：读了 A 又读了 B 又读了 C，参数每次都不同，重复检测一次都不会响，而它其实一直在原地。它最难发现的原因是**它看起来一直很忙**。
  4. 所以你需要一个**与具体工具无关的进展度量**，而任务清单正好提供了一个：清单的版本号多少轮没变。再加一个更严重的信号：同一条任务被从「已完成」重新打开了几次——它的意思是「它以为做完了，又发现没做完」，连续两次基本可以断定在兜圈子。两个信号加上轮数（本来就有的资源记账）就够了，不需要新的埋点。
  5. 干预分两级，**先给机会再抬头**：第一次命中回灌一条提醒（清单多少轮没动、请更新清单或说清卡在哪），这一轮照常继续；第二次命中才停下这一轮，走和硬上限完全一样的出口。两个实现细节值得讲：提醒要用 **user 角色**回灌而不是 assistant——assistant 消息会被它当成自己说过的话，于是它顺着原思路继续；user 消息才是「有人在催」。以及提醒事件复用现有的「可重试错误」那一位，**不给事件协议加新类型**，因为渲染层要知道的只是「循环接下来还会转一圈」。
  6. 最后是这题真正的深水区——**假警报的成本**。停滞检测必须有一条豁免：清单一次都没被写过时不判停滞。少了它，任何一次不用清单的短对话转到第三轮都会被提醒，而用户很快就学会无视所有提醒了。**一个会误报的守卫等于没有守卫**，这条判断比阈值调多少更重要。
  7. 可预期的追问：那三条硬上限（轮数、时长、token）算不算打转检测？不算，它们是资源兜底：**上限看的是花了多少，停滞看的是有没有进展。** 一个五轮就把 token 烧光的任务和一个转了八轮啥也没干的任务，是两种不同的失控，各需要一条闸。

  How to reason about it · think before answering

  1. The easy half-answer is detect repeated calls. That is one kind of spinning, but the easiest to catch and the less common one. The signal is naming the other shape and explaining why the first detector misses it.
  2. How to break it down: two shapes. Mechanical repetition — calling the same tool with byte-identical arguments over and over. And circling in place — doing something different every round while finishing nothing. For the first, key on tool name plus raw argument text and interrupt once consecutive hits reach a threshold. Three rulings matter: compare raw arguments, not meaning (a one-space difference means it is at least trying something new); count only consecutive hits (an intervening different call resets, because read, edit, read again to confirm is a healthy rhythm); and interrupt by feeding a result back, not by escalating to the user.
  3. The second shape is the common and hard one in long tasks: it read A, then B, then C, arguments differ every time, the repetition detector never fires, and it is still exactly where it started. It is hard to spot because it looks busy the whole time.
  4. So you need a tool-agnostic progress metric, and a task list supplies one: how many rounds the list's revision number has not changed. Add a more serious signal — how many times a single item has been reopened from done, which means it thought it was finished and then found it was not; twice in a row is close to proof of circling. Those two signals plus the round counter you already keep for resource limits are enough; no new instrumentation required.
  5. Intervene in two stages, giving it a chance before escalating: on the first hit, feed back a reminder (the list has not moved for N rounds, update it or state where you are stuck) and let the round continue; only on the second hit stop the turn, through the same exit as the hard limits. Two implementation details are worth mentioning: feed the reminder as a user-role message, not assistant — an assistant message reads to the model as something it said itself, so it continues the same line of thought, while a user message reads as someone prodding it. And reuse the existing retryable-error signal rather than adding a new event type, since all the render layer needs to know is that the loop will go around again.
  6. The real deep end is the cost of false positives. Stall detection needs an exemption: do not judge staleness when the list has never been written at all. Without it, any short conversation that legitimately skips the list gets nagged by round three, and users quickly learn to ignore every warning. A guard that misfires is no guard, and that judgment matters more than the exact threshold.
  7. Likely follow-up: do the three hard limits — rounds, wall time, tokens — count as spin detection? No, they are resource backstops. Limits watch how much you spent; stall detection watches whether you moved. A task that burns its token budget in five rounds and a task that spins for eight rounds doing nothing are different failures and each needs its own gate.

  答题要点

  • 打转有两种形态：机械重复（同工具同参数）与原地兜圈（每轮都不同但没进展）
  • 重复检测的三条口径：比参数原文、只看连续、打断方式是回灌而不是抬头
  • 兜圈要靠与工具无关的进展度量：清单版本号多少轮没变，加上同一条被重开几次
  • 干预两级：先回灌提醒（用 user 角色，不用 assistant），再命中才停下这一轮
  • 必须有豁免：清单没被用过就不判停滞——会误报的守卫等于没有守卫

  Key points

  • Two shapes: mechanical repetition (same tool, same arguments) and circling (different each round, no progress)
  • Three rulings for repetition: compare raw arguments, count only consecutive hits, interrupt by feeding back
  • Circling needs a tool-agnostic progress metric: rounds since the list's revision changed, plus reopen counts
  • Two-stage intervention: feed back a reminder first (as a user-role message, not assistant), stop only on the second hit
  • An exemption is mandatory: never judge staleness when the list was never used — a guard that misfires is no guard

评论