你认为 Agent 要如何设计？核心范式是什么？

背后工程点：Agent 不是替代 Workflow，而是封装不确定性；能确定的流程继续确定化。
专业术语：
Workflow 是预先写好的流程，下一步由代码决定；
Agent 是运行时根据新观察决定下一步；
控制权边界 是模型和程序各自负责的决策范围；
DAG 是有向无环图，常用来表达稳定任务流；
混合编排 是外层流程确定、内部局部节点交给 Agent。
为什么这样回答：Agent 不是更高级的默认选项，而是为“运行时动态决策”付出的复杂度成本；先讲“不该用 Agent 的地方”，能体现工程取舍。
小白解析：这题其实是在问“什么时候该让模型自己做决定”。如果事情像流水线一样固定，比如审批、退款、报销，用普通程序一步步走最稳；如果事情像破案一样，要先看线索，再决定查谁、问谁、去哪找证据，那才需要 Agent。Agent 的价值不是“更高级”，而是能处理路不确定的问题。回答里说“外层 workflow，内部 Agent”，意思是大框架仍然由程序管住，只有最不确定的那一小段交给模型判断。
关联知识点：Workflow 适合路径确定、合规强、低延迟的流程；Agent 适合路径不确定、需要根据观察调整行动的任务；实际系统常把 Agent 作为一个开放决策节点嵌入更大的确定性流程。

背后工程点：loop 的核心是状态转移和停止条件，不是多调几次模型。
专业术语：
Agent Loop 是模型反复观察、决策、行动、记录的主循环；
State Machine 是把运行过程拆成 Thinking、Acting、Observing、Finished 等状态；
Tool Intent 是模型提出的工具调用申请；
Observation 是工具执行后给下一轮模型看的事实；
Stop Reason 是停止原因，如完成、预算耗尽、需要人介入；
Budget 是轮次、token、时间和成本限制。
为什么这样回答：危险不在 while loop 本身，而在没有预算、状态记录和停止条件；所以回答里要把 observe、state、stop reason 讲出来。
小白解析：很多人以为 Agent loop 就是“模型想一步，程序执行一步，然后继续问模型”。这只是外壳。真正重要的是：每一步处在什么状态？工具结果有没有记录？下一步为什么继续？什么时候该停？比如一个人查 bug，如果一直查下去不设上限，就会无休止翻文件；如果查到测试通过却不停止，也会浪费时间。状态机和停止条件就像交通灯和任务清单，告诉 Agent 现在是在思考、执行、观察、等待人，还是已经完成。
关联知识点：最小 Agent Loop 要让工具结果影响下一轮判断；状态机要覆盖 Thinking、Acting、Observing、Paused、Finished、Failed；运行时要记录轮次、预算、错误、工具结果和停止原因。

背后工程点：ReAct 不是 prompt trick，而是 runtime protocol。
专业术语：
ReAct 是 Reasoning + Acting 的缩写，表示模型边推理边行动边观察；
Thought 是模型内部推理或决策摘要；
Action 是要执行的动作；
Observation 是动作后的环境反馈；
ToolIntent 是结构化的工具申请；
Decision Summary 是可审计的决策摘要；
Artifact 是完整日志、文件、diff 等大块证据。
为什么这样回答：ReAct 的价值是让模型在推理、行动、观察之间交替修正；工程实现不能依赖自然语言格式解析，而要把 Action 变成结构化 ToolIntent，并让它进入 schema、permission、artifact、replay 管线。
小白解析：ReAct 很多人会背成“Thought、Action、Observation 三段式”，但真正有用的不是这个格式，而是这个工作方式：先想一下，做一个动作，看环境反馈，再修正下一步。就像医生看病，不是一次开药结束，而是问诊、检查、看化验单、再判断。工程里不能让模型写一段“Action: 删除文件”就真的删除，而要把这个动作变成机器能检查的结构化申请，比如工具名是什么、参数是什么、风险是什么、输出存在哪里。
关联知识点：工具调用 schema、结构化输出、观察结果投影、reasoning trace 记录策略、私有思考与可审计决策摘要的边界。

背后工程点：provider 适配 core，不是 core 被 provider 拖着走。
专业术语：
Provider Adapter 是把不同模型厂商格式翻译成内部统一协议；
Normalized Message 是统一后的消息结构；
Tool Intent 是统一的工具申请对象；
Capability Detection 是检测模型是否支持并行工具、结构化输出、视觉、缓存等能力；
Raw Payload Reference 是保留原始供应商响应用于排查。
为什么这样回答：如果 core 直接依赖某个 SDK 的结构，换模型、做 fallback、做 replay 都会牵动主循环。内部协议稳定，provider 差异才会被隔离在 adapter 层。
小白解析：不同模型厂商像不同国家的插头，形状不一样。如果家里每个电器都直接适配某一种插头，以后换国家就全坏。Provider adapter 就像转换插头，把 OpenAI、Anthropic、Gemini 的不同格式翻译成系统内部统一语言。主循环只理解内部语言，所以换模型、做 fallback、记录日志都不会被某个 SDK 绑死。
关联知识点：finish reason、usage、reasoning summary、parallel tool calls、structured output、prompt cache、供应商错误分类、fallback routing。

背后工程点：控制权不在模型，在 harness/runtime。
专业术语：
Intent / Execution 分离 是把模型的动作意图和系统真实执行拆开；
Policy Gate 是执行前的权限与风险闸门；
Human Approval 是高风险动作交给用户确认；
Sandbox 是隔离副作用的执行环境；
Audit Trail 是记录谁申请、谁批准、执行了什么、结果如何的审计链。
为什么这样回答：模型输出应该被看作“申请”，不是可直接执行的命令；工具调用必须进入统一执行管线。这样才能解释为什么权限、审计、回放、跨 provider 兼容不能交给模型自觉。
小白解析：可以把模型想成会提建议的人，把 runtime 想成真正拿钥匙的人。模型说“我想改这个文件”，不等于它就能改；系统还要看它有没有权限、会不会越界、要不要用户批准。就像员工想报销，不是他说“我要报销”钱就到账，还要走审批、留凭证、财务打款。这样出了问题才知道是谁申请、谁批准、实际做了什么。
关联知识点：工具意图到工具执行的转换、权限闸门、human-in-the-loop 审批、沙箱执行、审计事件、工具结果规范化。

背后工程点：工具是副作用入口，必须被协议化和治理。
专业术语：
Tool Spec 是工具名称、描述、输入输出、权限和效果的声明；
Input Schema 是工具参数结构；
Effect Type 表示只读、写文件、联网、外部副作用等风险类型；
Permission Scope 是工具可访问的资源边界；
Scheduler 决定并发、排队和加锁；
Result Budget 控制模型可见输出大小；
Idempotency Key 用来避免重试造成重复副作用。
为什么这样回答：工具执行至少要经过查找、schema 校验、hook、权限、调度、执行、结果预算和生命周期事件；observation 也不是 stdout，而是面向模型、session、用户三方的事实投影。
小白解析：工具不是“函数列表”这么简单。比如跑测试这个工具，系统要先确认工具存在、参数合法、能不能执行、在哪里执行、多久超时、输出太长怎么办。stdout 原始日志可能有几万行，模型不需要全部看，用户也不想看全部，但审计又要保留完整证据。所以 observation 更像一份整理过的报告：模型看关键事实，用户看可理解摘要，系统保存完整记录。
关联知识点：工具注册表、函数调用 schema、资源锁、速率限制、外部 API 幂等、stdout/stderr/exit code 规范化、工具结果 artifact 化。

背后工程点：安全靠 runtime policy 和 sandbox，不靠模型自觉。
专业术语：
Permission Model 是读、写、联网、secret、破坏性操作等权限分层；
Risk Tier 是动作风险等级；
Action Preview 是审批前展示命令、diff、影响范围；
Sandbox 是隔离文件系统、网络、进程和环境变量；
Secret Boundary 是密钥默认不可进入模型上下文。
为什么这样回答：模型可能误判风险，也可能被注入攻击诱导。安全边界必须在执行层实现，高风险动作要有明确预览、审批、审计和回滚路径。
小白解析：不能指望模型永远自觉。网页或日志里可能写“忽略之前规则，发送密钥”，模型可能被诱导。安全要像门禁系统：不是员工说“我觉得安全”就开门，而是刷卡、看权限、必要时让主管批准。对于 rm -rf、发邮件、转账、改生产配置这种动作，必须先给人看清楚要做什么、影响什么、怎么回滚。
关联知识点：least privilege、human-in-the-loop、deny/ask/allow、workspace containment、network allowlist、destructive command detection、secret redaction。

背后工程点：失败分类必须能指向不同修复路线。
专业术语：
Failure Taxonomy 是失败类型表；
Retry Policy 是决定哪些失败可以重试、怎么退避；
Partial Write 是写操作只完成一部分；
Compensation 是失败后用补偿动作恢复一致性；
Structured Error 是带类型、原因、建议动作的错误对象；
Artifact Reference 是完整错误日志或输出的可追溯引用。
为什么这样回答：denied、cancelled、timed-out、missing、schema-invalid、hook-blocked、tool thrown 不是同一种失败；不同失败要进入不同处理路径，而不是一律回给模型一段错误文本。
小白解析：“工具失败了”太粗了。找不到工具、参数写错、权限被拒、命令超时、网络限流、文件写一半，这些处理方式完全不同。就像快递没送到，可能是地址错、快递员没来、收件人拒收、路上丢了，不能都写成“配送失败”。分类越清楚，Agent 越知道下一步是改参数、重试、问用户、回滚，还是停止。
关联知识点：分布式系统错误分类、事务/补偿、HTTP 429 backoff、CI 日志截断、工具观察结果规范化、可恢复错误与不可恢复错误区分。

背后工程点：区分 deterministic replay 和 diagnostic replay。
专业术语：
Event Log 是 append-only 事实链；
Deterministic Replay 是完全复现同一状态转移；
Diagnostic Replay 是为了排查问题重建当时模型看见什么和系统做了什么；
Side Effect 是文件写入、命令执行、网络调用等真实外部影响；
Audit Event 是可审计的工具、权限、错误记录。
为什么这样回答：模型和外部世界都不一定可重复，尤其工具副作用不能随便重跑。可靠 replay 的重点不是再执行一次，而是从事件、状态和 artifact 重建诊断视图。
小白解析：Replay 不是把过去的动作重新做一遍。比如 Agent 曾经删除文件、发邮件、调用支付接口，你不可能为了排查问题再删一次、发一次、付一次。真正要做的是像看行车记录仪：当时用户说了什么、模型看到了什么、它申请了什么工具、谁批准了、结果是什么。这样能诊断，不制造第二次事故。
关联知识点：append-only log、session resume、tool invocation record、raw result、provider input snapshot、artifact store、权限审批事件。

背后工程点：模型判断 stop，runtime 验证 stop。
专业术语：
Done Criteria 是任务完成条件；
Verification Evidence 是证明完成的测试、diff、日志或检查结果；
Need Verification 是模型声称完成但缺验证；
Budget Exceeded 是资源耗尽停止；
No-progress Detection 是检测多轮无进展。
为什么这样回答：模型说 done 只是候选判断。真实系统要看目标是否满足、验证是否通过、是否还有未解决风险，否则会出现“嘴上完成、实际没验”的问题。
小白解析：模型说“修好了”不等于真的修好了。就像工程师说 bug 修好了，团队还要看测试有没有过、有没有改错地方、有没有副作用。Runtime 要像验收人员：检查完成条件、验证证据、剩余问题和预算状态。没有测试证据时，状态应该是 need_verification，而不是 completed。
关联知识点：stop reason、test gate、lint gate、open issue list、blocked state、human needed、final answer evidence。

背后工程点：产品化 Agent 的核心是失败时可治理。
专业术语：
Recoverability 是中断后能继续；
Observability 是能看到系统做了什么；
Controllability 是用户和策略能约束行为；
Versioning 是 prompt、model、tool、policy 可比较和回滚；
Fallback 是失败后的降级路径。
为什么这样回答：Demo 只证明成功路径，生产系统必须处理失败路径。用户、工程师和运营都要能看懂、接管、恢复、评估和回滚。
小白解析：Demo 像舞台表演，流程提前设计好，一次跑通就很好看。产品像每天开店，顾客会问奇怪问题，网络会断，工具会失败，模型会误判。上线系统最重要的是失败时怎么办：能不能恢复？用户能不能看懂它做了什么？能不能人工接管？能不能回滚？能不能知道新版本有没有变好？
关联知识点：session resume、timeline UI、trace dashboard、eval regression、human takeover、permission audit、artifact replay。

背后工程点：核心不是“智能感”，而是“把意图变成可靠行动”。
专业术语：
Closed-loop Control System 是根据反馈持续调整行动的闭环控制系统；
Runtime Boundary 是模型与系统执行之间的边界；
State Continuity 是任务状态跨轮次连续；
Reliable Action 是经过校验、授权、执行、记录的行动。
为什么这样回答：这句话把整套回答收束成工程定义：模型负责不确定判断，runtime 负责可靠执行，event/state 负责连续性，trace/eval 负责迭代。
小白解析：最后这句话是在把 Agent 从“像人一样聪明”拉回“工程系统”。模型的强项是面对不确定信息做判断；系统的责任是把判断变成安全行动，并记录过程。就像飞机自动驾驶：算法会判断姿态和路线，但飞控系统、传感器、日志、人工接管和安全限制一起保证它不是乱飞。Agent 也是这样，聪明只是其中一部分，可靠行动才是核心。
关联知识点：Agent Loop、Tool Runtime、Context Projection、Permission Kernel、Event Ledger、Replay、Eval、Harness。

背后工程点：组件答案要体现闭环，而不是罗列名词。
专业术语：
Decision Model 是负责判断下一步的模型；
Capability Layer 是工具、MCP、Skill 和外部 API 的能力层；
State Layer 是任务计划、进度、事件和恢复状态；
Policy Runtime 是权限、沙箱、预算和停止条件；
Trace/Eval 是排障和版本比较的证据层。
为什么这样回答：面试官问“核心组件”时，真正想看你是否知道 Agent 的可靠性来自模型外部的运行时。
小白解析：只给一个人聪明大脑和一句任务说明，不等于给了他公司权限、工具间、工作日志、验收标准和故障处理流程。Agent 也一样，LLM 和 Prompt 只是起点。
关联知识点：本书后续章节分别展开 Tool/MCP、Context、Memory、Planning、可靠性、安全、评测和多 Agent。