Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D3 Getting Started With the Pi SDK: the Three-Layer Architecture, Comparing It to the Agent Loop (dg P01/P02/M02/M03)

• Once you adopt an agent framework, how do you know what it is doing internally, and where do you start debugging?用了 Agent 框架之后，你怎么知道它内部到底发生了什么？出问题从哪里查？

  Common in ChinaCommon overseasDeep dive#observability#framework-design#debugging

  How to reason about it · think before answering

  1. This is the hands-on version of the framework-versus-hand-rolling question, and it tests whether you have actually debugged on top of a framework. 'Add logging' is the weakest answer, because the loop is no longer in your code and there is nowhere to add it.
  2. Name the right observation point: the event stream. One run emits run start, each turn's start and end, message start and deltas and end, tool execution start and end, and run end. Those events are the loop's steps projected outward — turn start and end correspond to one iteration of your hand-written for loop, and run end to your return statement.
  3. Give a reusable triage chain, taking 'the tool never ran' as the example: check whether a tool-execution-start event was emitted. If it was, the problem lives in execution — arguments, implementation, timeout. If it was not, the model never decided to call it, so the problem is the tool description or the parameter schema and has nothing to do with the implementation. That single split removes most guesswork.
  4. Add two more threads: locate the failure by layer, since a model-layer stack points at auth, model id or request shape while a kernel-layer stack points at the loop or tool execution; and pin the framework version, because defaults shift between releases and 'behavior changed with no code change' almost always means an upgrade.
  5. Volunteer the production angle: the event stream is not just for debugging, it is the observability seam where per-step latency, tool success rate and token or cost accounting are collected. Warn that text-delta events fire per token, so heavy work in that callback stalls the stream — batch first, then process.
  6. Expect the follow-up: what if the framework does not expose the hook you need? Try dropping a layer first (bypass the application layer and drive the kernel directly), then its extension mechanism for intercepting around tool calls; forking is the last resort, and its real price is owning upstream merges forever.

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

  1. 这题是「框架 vs 手写」那道题的实操版，考的是你有没有在框架上真的排过障。答「打日志」是最弱的答案，因为循环已经不在你的代码里了，你没有地方插日志。
  2. 先给正确的观察位置：框架的事件流。一次执行会依次发出运行开始、每一轮的开始与结束、消息的开始与增量与结束、工具执行的开始与结束、运行结束。这些事件就是循环的每一步在外部的投影——轮次的开始与结束对应手写版 for 循环的一次迭代，运行结束对应你 return 的那一刻。
  3. 给一条可复用的排查链：以「工具没被调用」为例，先看事件流里有没有发出工具执行开始的事件。发出了就是执行阶段的问题（参数、实现、超时）；没发出就说明模型压根没决定调它，问题在工具描述或参数 schema，跟工具实现一点关系都没有。这条二分法能省掉大量瞎试。
  4. 补上另外两条线索：一是分层定位，报错栈落在模型层就查鉴权、模型 id 与请求格式，落在内核层就查循环与工具执行；二是把框架版本锁死，因为默认值随版本变化，「代码一行没改但行为变了」这类问题的第一嫌疑人就是升级。
  5. 生产视角要主动说：事件流不只是调试用的，它是可观测性的接入点——每一步耗时、工具成功率、token 与成本归集都从这里接出去。但要提醒一句，文本增量事件是逐 token 触发的，回调里做重活会拖慢整条流式链路，正确做法是攒一批再处理。
  6. 可以预期的追问：如果框架没有暴露你需要的那个钩子怎么办？答先看它的分层能不能降一层用（比如绕过应用层直接用内核层），再考虑用它的扩展机制在工具调用前后插手；实在不行才是 fork，而 fork 的代价是你从此要自己跟上游合并。

  Key points

  • Observe through the event stream, not ad-hoc logs: run start, turn start and end, message deltas, tool execution start and end, run end
  • Turn start and end map to one iteration of the hand-written loop, and run end maps to the return — that mapping makes any event table readable
  • Triage split: if a tool never ran, check for a tool-execution-start event; present means debug the implementation, absent means debug the description and schema
  • Locate by layer — model-layer stacks mean auth or model id, kernel-layer stacks mean the loop or tool execution — and pin the framework version, since upgrades silently move defaults
  • The event stream is also the observability seam, but text deltas fire per token, so batch before doing real work in that callback

  答题要点

  • 观察位置是框架的事件流，不是日志：运行开始、轮次开始与结束、消息增量、工具执行开始与结束、运行结束
  • 轮次的开始与结束对应手写版循环的一次迭代，运行结束对应 return，能做这个映射就能读懂任何事件表
  • 排查二分法：工具没被调用时，先看有没有发出工具执行开始的事件——发了查实现，没发查描述与 schema
  • 按分层定位：模型层的栈查鉴权与模型 id，内核层的栈查循环与工具执行；同时锁死框架版本，升级是行为变化的第一嫌疑人
  • 事件流也是可观测性接入点，但文本增量事件极其频繁，回调里不要做重活，攒一批再处理