产品经理的 Agent 入门
Agent 的运行过程
看懂 Agent Runtime 怎样组装上下文、调用工具、更新状态，并在正确的条件下继续或停止。
「产品经理的 Agent 入门」之三
上一篇：Agent 的适用场景 · 系列入口 · 下一篇：上下文、会话与记忆
当界面只显示一个聊天框时，Agent 很容易看起来像模型自己完成了一切。实际上，模型只是一次次给出下一步判断；真正让任务运行起来的是 Agent Runtime。
**Agent Runtime（运行时）**是承载一次 Agent 任务的程序环境。大白话说，它像 Agent 的操作系统：决定模型看到什么、可以调用什么、动作在哪里执行、过程如何记录，以及什么时候必须停。
一次任务的完整链路
Chat / API / 定时任务
↓
识别用户、目标和风险
↓
Context Builder 组装规则、资料、记忆和工具定义
↓
模型选择：回答 / 调工具 / 追问 / 请求确认
↓
Runtime 校验参数与权限，执行 Tool
↓
把结果或错误返回模型
↺
达到完成、失败、上限或人工确认条件
↓
保存结果、状态和审计记录中间反复发生的“模型判断—工具执行—读取结果”，就是 Agent Loop。
Runtime 要负责什么
| 职责 | 产品问题 |
|---|---|
| Entry | 谁从哪个入口发起任务？ |
| Context Builder | 哪些规则固定加载，哪些资料按需召回？ |
| Loop | 最多执行几步，成本和时间上限是多少？ |
| Tool Layer | 参数如何校验，动作有什么副作用？ |
| State | 刷新、中断或交接后怎样继续？ |
| Memory | 什么值得跨任务复用，谁能修改？ |
| Permission | 谁能代表谁，对什么对象做什么？ |
| Observability | 出错后能否看到步骤、耗时和成本？ |
| Evaluation | 怎样区分“有输出”和“任务完成”？ |
产品经理不一定实现这些模块，但必须在需求和验收中为它们留下位置。
Context Builder 往往比换模型更重要
模型不会自动知道企业数据、项目规则或刚修改的文档。Runtime 必须选择真正相关的信息放进每次 Context。全量注入会带来噪声、延迟、旧信息冲突、敏感信息越界和难以回源。
同一个模型在不同产品里的表现差异，经常来自 Context、Tool 和反馈循环，而不是模型突然变聪明。
结束条件比循环更重要
可控 Agent 至少要知道什么时候已经完成、什么时候需要追问、工具失败后如何处理、何时达到步骤或成本上限、何时必须审批，以及何时应明确失败。
“一直做直到做好”并没有定义完成标准和失败边界。
本篇小结
- 模型每一轮只根据当前 Context 提出下一步；Runtime 才负责执行、记录和控制整个任务。
- Agent Loop 是“模型判断—工具执行—结果返回—状态更新”的重复过程，不是模型在后台无限思考。
- 结束条件必须覆盖完成、追问、失败、预算上限和人工确认，不能只写“直到做好”。
模型判断下一步可能是什么；Runtime 决定它能不能做、在哪里做、怎样记录，以及何时必须停。