这两年圈子里聊 Agent 的人越来越多，但真正把 Agent 讲透的内容反而更稀缺。我最近给一个业务团队做技术咨询时，反复用到一个视角：把 Agent 当成一台新发明的计算机来理解。这个比喻一开始只是为了方便沟通，后来发现它几乎能解释 Agent 领域所有让人困惑的问题——为什么上下文窗口这么重要，为什么工具调用会失败，为什么各家平台长得不一样但内核又极其相似。所以这篇内容，我想从头拆一拆这个想法，顺便把我在实际项目里踩过的坑、总结出的判断标准一起放进去。无论你是刚入行的工程师，还是已经在写 Agent 应用的产品同学，看完应该能建立起一套自己的分析框架。
1. 为什么说 Agent 是一台新计算机——一个值得认真对待的隐喻
1.1 传统计算机的“部件”在 Agent 里全都能找到对应物
计算机系统的经典五部件：输入、输出、存储、运算、控制。对应到 Agent 上，模块几乎是一一对应的。运算部件是大语言模型，负责推理和生成；存储部件分两层，短期存储是上下文窗口，长期存储是向量数据库或者外部文件系统；输入部件是用户消息和工具返回结果，输出部件是文本生成和工具调用指令；控制部件则是最关键的编排逻辑，决定模型下一步去调用哪个工具、什么时候终止循环。
我见过很多团队，一开始用的是纯提示词工程，把一个复杂任务塞进一段超长 prompt 里，期望模型能自己完成。这种做法相当于在计算机时代手动拨动继电器，理论上可行，但根本不是工程化的做法。后来他们转向 Agent 架构，本质上是给这个“新型计算机”装上了操作系统，把原来由人肉控制的流程，变成了由框架调度的任务循环。
这个隐喻的价值在于：一旦你承认 Agent 是一台计算机，很多“这个能做吗”“那个能做吗”的问题就有了统一的解答路径。比如为什么需要记忆管理？因为任何计算系统都需要寄存器、缓存、磁盘的分层。为什么要设计工具协议？因为外设需要标准接口，否则驱动没法写。
1.2 从“程序”到“推理系统”的范式转移
传统软件是确定性的：同样的输入，走同样的代码路径，输出必然一样。Agent 完全不是这样，它是概率性的推理系统，同样的输入，可能因为模型温度、上下文顺序、甚至一个空格，产生不同的输出。这种差异，让很多老工程师非常不适应。
我在一个传统后端团队分享 Agent 架构时，有位同学问了一个特别典型的问题：“我给它一个 JSON，它返回的字段偶尔会对不上，这怎么测？”这个问题的本质，是把 Agent 当成了普通函数——传参、执行、返回结果，期望它是一个纯函数。
但如果你把它当作一台计算机，思路就会完全不同。你不会用单元测试的断言方式去验证一个操作系统，而是会去检验它的模块是否可靠、调度是否合理、容错是否到位。所以现在团队里普遍引入了一套新的测试思路：回归集、语义打分、任务完成率，而不是简单的断言等于不等于。
从“函数调用”思维切换到“计算平台”思维，是做好 Agent 的第一道门槛。这道坎跨不过去，后面所有工程决策都会变形。
1.3 大脑记忆：为什么不搞记忆就无法真正落地
承接前面的类比，记忆问题可以继续延伸。传统计算机有严格的内存层次结构，从寄存器到缓存到主存到磁盘，每一级的速度和容量都有不同的取舍。Agent 的上下文窗口就相当于主存，容量有限、访问快、但会满；向量检索相当于磁盘索引，容量大、访问慢、需要一次寻址。
多数产生于团队的失败案例，都和“主存装不下”有关。一次任务需要读 20 份文档，每份 2000 token，硬塞进上下文就会超限，硬截断又会丢信息。后来他们采用类似虚拟内存的分页机制：把文档切片、做摘要、按需检索，才把这个瓶颈绕过去。这种设计，本质上就是操作系统的内存管理策略。不要觉得这是过度抽象，真正做过长任务 Agent 的人都会认可这个方向的实用价值。
2. 被忽视的“硬件层”：模型能力、上下文窗口与工具调用的物理瓶颈
2.1 大语言模型是 CPU——但它有自己的“硬件规格”
如果接受 Agent 是台计算机，那么大语言模型就是它的 CPU。这个 CPU 的主频不是 GHz，而可以用推理延迟来衡量；它的指令集不是 x86，而是“下一个 token 的概率分布”。很多团队选型时只看模型在跑分榜单上的排名，很少关注真正决定上线体验的三个指标：首 token 延迟、吞吐量、幻觉率。
我自己的经验是，在实际 Agent 场景里，幻觉率比单项能力评分重要得多。评分测试大多考察单轮问答，Agent 场景则要求模型在多次工具调用后依然保持状态一致性。有些模型单看对话能力很强，但一进入多轮工具调用就暴露问题：重复请求、提前终止、把工具返回结构当成对话内容输出。这类问题在离线测试里很难发现，必须放到真实任务里跑。
这里给一个便宜的判断方法：收集 50 条真实用户请求，让 Agent 逐一执行，记录“是否完成任务、是否用了正确工具、是否产生无效输出”三个指标。一次测试跑下来，哪个模型能用、哪个模型会翻车，比任何评测榜单都直观。
2.2 上下文是内存，但内存会碎片化
传统程序的内存会碎片化，Agent 的上下文也会。很多开发者的第一版实现，把每轮工具调用结果全部堆进上下文，结果上下文被大量 JSON 片段占据，模型越来越“看不到”最初的用户目标。这就是内存碎片化在 Agent 里的表现形式。
解决思路是给上下文做整理，相当于加了一个 GC（垃圾回收）。我在项目中惯用的方案有几层：对工具返回做结构化摘要而非完整保留，只保留与当前任务相关的字段；在每轮循环开始前，把“系统目标”作为不可变前缀反复强化；对历史对话做滚动裁剪，只保留最近几轮和关键决策点。这套机制让上下文占用减少了约 40%，任务完成率显著提升。
用 Token 预算做类比：上下文窗口相当于物理内存，预算分配等于进程地址空间规划。如果让一个 Agent 进程无限制往主存里写数据，系统迟早会 OOM。提前规划每个阶段的 token 配额，比如“系统指令占 10%、历史对话占 30%、工具返回占 40%、用户输入占 20%”，是避免这类问题的可行办法。
2.3 工具调用是外设，驱动写不好主机就跑不起来
传统计算机接打印机需要装驱动，Agent 接业务系统需要写工具。但很多团队把工具注册写得很随意：一个函数名加一句简单描述。人眼能看懂，但对模型来说，工具声明就是它的“调用手册”，手册写不清楚，模型自然乱来。
我在一个跨系统自动化的项目里第一次吃这个亏。当时为了让 Agent 调用订单查询服务，工具描述只写了“查询订单信息”。结果模型经常在其他任务里也去调用这个工具，白白消耗时间和成本。后来我把工具描述改成结构化格式：用途说明、适用场景、不适用场景、参数含义、返回值示例、失败时的替代方案。改完之后，工具误调率明显下降。
这里提几项工具注册的必备信息，你可以直接参考下表：
| 工具字段 | 作用 | 典型写法 |
|---|---|---|
| 用途 | 告诉模型这个工具是干什么的 | 按订单号查询订单当前状态 |
| 适用场景 | 什么情况下优先使用 | 用户在询问物流进度、退款状态时使用 |
| 不适用场景 | 什么情况下不要使用 | 不适用于查询用户历史订单列表 |
| 参数说明 | 明确每个参数的类型和约束 | orderId: string，必填，32位数字字符串 |
| 返回示例 | 给出真实返回结构的片段 | {"status": "SHIPPED", "trackingNo": "SF..."} |
| 错误处理 | 失败时如何重试或降级 | 服务超时后最多重试2次，仍失败则提示用户稍后再试 |
这套做法做下来非常符合我的工程习惯，也直接减少了模型乱调工具的活跃度。
3. 操作系统之争：Agent 运行时、编排协议与工具标准化的三层博弈
3.1 Agent 的运行时不只是一个库，而是一个“引导层”
把 Agent 框架比作操作系统，最直观的体验是看启动流程。一个传统的 Python 脚本，从上到下逐行执行，而一个 Agent 进程的启动，需要完成“目标解析、角色设定、工具清单加载、记忆恢复、路由策略初始化”等多个步骤。这些步骤如果写死在业务代码里，每次改动都要大动干戈；如果抽象成一个运行时，由声明式配置来驱动，那么换场景、换工具、换模型就都能集中管理。
我在今年参与的某跨平台系统里，团队选型了一个轻量的开源编排框架，把 Agent 的启动配置与业务逻辑分离。业务同事只需要维护一份 YAML 文件，里面写好系统角色、工具列表、最大轮次、退出条件，不用关心内部调度逻辑。这个配置就是 Agent 操作系统的启动引导。团队成员适应得很快，因为从“写脚本”到“写配置”这个转变，恰恰印证了计算机分层设计的价值。
3.2 工具标准的“即插即用”化趋势
操作系统能普及，是因为有了统一的外设接口标准。Agent 生态也在经历同样的过程。当前服务集成方式百花齐放，各家定义各自的工具格式，都有 schema、协议、鉴权方式。这种碎片化对 Agent 应用开发者来说很痛苦，每接一个外部系统都要重新适配一套接口逻辑。
我最近在调研新的工具协议，倾向于一种“函数说明 + HTTP 调用”的中性格式。它不绑定特定框架，而是用一套通用描述文档声明工具能力，运行时按声明的端点实际发起请求。这个做法把“工具仓库”推到外部，Agent 平台更像一个硬件插槽，任何符合规范的函数都可以插上去用。这一步还在早期发展阶段，但已经能明显看出标准化的趋势。
3.3 选型判据：别只盯功能列表，先盯调试链路
每次给团队做框架选型，我最关心的不是框架有多少内置工具、支持多少个模型，而是调试链路是否通畅。Agent 应用是状态很强的系统，出问题后第一件要做的事就是看推理过程：模型上一轮在思考什么，为什么决定调用某个工具，工具返回了什么，模型又如何消化这些数据。这些信息若不能在界面上直观回放，你的排障成本将被无限放大。
我见过一个团队选了功能最多、但可观测性很差的框架，上线一周后完全无法定位“为什么 Agent 突然开始乱回复”。后来手工在每次循环里插入日志，才发现是工具返回的 JSON 里有一个字段格式变了，但那已经是线上事故之后了。现在我对框架的第一个筛选条件就是：能不能一键回放整条推理链路，能不能标记出每轮 token 成本。做不到这两点，功能再全也不选。
我把框架选型比喻成选操作系统：大家更在意的是生态、兼容性和排障体验，而不是某个预装小工具好不好用。
3.4 算力调度与成本控制：分布式 Agent 的瓶颈
Agent 进入生产之后，紧接着会暴露一个传统计算机工程早就解决的问题：资源调度。文本模型推理成本高、延迟高，如果每个业务请求都构造一次完整 Agent 循环，成本会成倍放大。这里可以借鉴操作系统的进程调度策略，为不同类型的任务分配差异化的执行路径。
简单任务走直连模式，让模型一次生成答案，不需要工具调用；中复杂度任务只做单轮工具调用，业务参数从输入里直接提取；长链路任务才启用完整 Agent 循环，并限制最大迭代轮次。这个分层调度规则，可以让企业级 Agent 平台的单位成本下降约 50%，而用户体验几乎没有衰减。调度策略写在公共配置里，团队所有成员都共用同一套分层规则，避免私下各写各的超时和重试逻辑。
4. 应用层的一次最小实现：我搭值班助手 Agent 的真实过程
4.1 场景定义与需求拆解
理论讲了那么多，还是得拿一个实际例子，才能真正理解“Agent 即计算机”意味着什么。我最近搭的一个内部值班助手，功能听起来很简单：收到值班群消息后，自动查询服务状态、拉取错误日志、判断是否需要人工介入、最后生成一条值班小结。
这个看起来简单的小工具，拆解后其实包含一个完整的 Agent 系统：输入模块对接消息平台，感知模块分析消息意图，规划模块决定“查状态”还是“查日志”，工具层对接监控系统的开放接口，记忆模块保存前几轮值班的历史结论，最后输出模块生成人类可读的报告。整体架构就是一个微型计算机。
我选这个场景做最小实现，还因为它同时包含两类核心技术点：结构化工具调用和多轮状态保持。值班消息往往不完整，比如用户只发一句“支付服务好像挂了”，Agent 需要补全服务名、确定时间范围、查询日志，给出一个可读结论。这个过程模拟了真实生产环境里 Agent 最有价值的形态。
4.2 工具层设计：一个查询接口的完整注册示例
先看一下我注册的第一个工具。它是查询服务状态的接口。代码是我实际在项目里使用的形式，你可以直接参考：
{ "tool_name": "get_service_status", "description": "查询指定服务当前的健康状态和最近一次异常时间", "parameters": { "type": "object", "properties": { "service_name": { "type": "string", "description": "服务名称，必填，例如 payment/order/user" }, "time_range": { "type": "string", "description": "查询时间范围，可选，默认最近5分钟", "enum": ["5m", "30m", "1h", "6h"] } }, "required": ["service_name"] }, "returns": { "status": "healthy|degraded|down", "last_exception": "string|null", "detail": "object" } }这里有一个细节值得单独提一下：枚举参数一定要写全。模型接到 time_range 这个参数时，如果描述里没有候选值，它有可能发明一个新值，比如“today”。一旦发明出 schema 里不存在的值，工具调用就会失败，白白浪费一轮迭代。枚举约束是主动帮模型避免犯错的机制，而不是限制能力的功能。
4.3 Agent 主循环：调度器与重试策略
值班助手的核心主循环，我用一段示意性伪代码来说明。它本质上是一个“感知-规划-行动-观察”的循环，直到满足退出条件。
async def agent_loop(task_input, max_rounds=5): context = { "system_prompt": SYSTEM_PROMPT, "user_goal": task_input, "observations": [] } for round_id in range(max_rounds): plan = await llm_step(context) if plan.intent == "finish": break if plan.tool_name not in tool_registry: context["observations"].append({ "round": round_id, "error": "tool_not_found", "message": f"工具 {plan.tool_name} 未注册，请检查拼写" }) continue result = await execute_tool( plan.tool_name, plan.arguments, retry=2, timeout=10 ) context["observations"].append({ "round": round_id, "tool": plan.tool_name, "result_snapshot": summarize(result) }) response = await llm_generate_summary(context) return response我在代码里刻意隐藏了几个工程细节，这些细节是线上 Agent 和工作 Demo 拉开差距的核心原因：
summarize(result)：工具返回往往很长，结构也复杂，直接把原样塞进上下文会迅速填满内存。这个函数会抽取关键字段生成摘要，减少上下文污染。retry=2, timeout=10：外部系统不稳定是常态，模型第一次调用失败时，自动重试可以显著提高成功率。但重试次数不能太多，否则成本剧增。tool_not_found：当模型编造出不存在的工具名称时，不终止进程，而是把这个错误当成一条观察结果反馈给模型，让它自己修正方向。这比直接抛异常更符合 Agent 的容错哲学。
4.4 大语言模型既能执行工具，也会“胡言乱语”
值班助手上线第一天就暴露了一个意想不到的问题：它会在查询日志之后把它截获到的一段原始错误堆栈直接输出到聊天群。对用户来说，这既看不懂也吓人。根源在于模型认为原生工具结果就是用户想要的答案，缺少了“翻译”这一步。
修复方法很简单，在系统提示词里强调一条规则：所有工具返回内容必须经过你的理解提炼，以人类可读的方式输出，不得原样粘贴原始数据。同时我还增加了输出约束，规定最终回复必须以结构化分块呈现：当前状态、异常摘要、建议动作。跑过几轮后，值班助手的输出质量有了明显提升。
这个经验背后其实是 Agent 计算机的输入-输出原则：内部总线上的原始信号，不一定适合直接暴露给用户。传统操作系统也这样，内核日志和用户界面是分开的，Agent 同样需要这种输出分层设计。
4.5 可观测性是一次性搭好的基础设施
值班助手从一开始就把每次循环的中间推理轨迹落库。每条记录包含：模型对当前问题的分析文本、选择的工具及参数、工具返回摘要、最终回复全文。这让我在排查问题时省了非常多时间。
有一次助手反复把“服务健康”判断成“服务异常”，我打开轨迹记录，发现是查询参数 time_range 默认返回了近 6 小时的数据，而旧数据里包含一条凌晨三点的历史异常，被模型误认为当前异常。如果不看轨迹，单看最终结果，你根本无法定位问题所在。这个案例说明，Agent 可观测性的价值甚至高于传统服务——因为它的中间过程比最终结果更能揭示问题。
通用原则：任何 Agent 系统上线前，至少保留过去 100 条真实循环的完整轨迹。这一条数据就是你的灰度测试集，也是排障的现场回放记录。
5. 这台计算机的现实边界：可靠性、反馈闭环与长期记忆的死角
5.1 可靠性：概率系统的宿命与缓解策略
传统计算机只要硬件不坏，指令执行结果就是确定的，Agent 没法给你这个保证。模型可能在前一轮还流畅执行任务，后一轮突然对一个陌生输入给出不合理输出。这种不确定性是概率系统的本质，不是某个参数调了就能消除的。
对可靠性要求极高的业务，目前可行的思路不是追求“模型永远对”，而是给错误留出足够的逃生通道。我在值班助手项目里做的几件事反馈很好：给每个工具调用包裹一层 schema 校验，参数不符合规范就直接报错反馈给模型，让它自己重新构造参数；为所有外部 API 调用都做超时与熔断，工具不可用时降级为“提示用户稍后手动处理”；任务结束前增加最终校验环节，针对特定任务类型检查结果关键字段是否合理。
这套“错误容忍 + 快速降级”的思路，借鉴了操作系统的稳定设计哲学。你不可能让 CPU 永远不崩溃，但你可以让系统在崩溃时快速重启、优雅降级。
5.2 评价体系：用回归集替代直觉判断
很多团队问“怎么知道 Agent 变好了还是变坏了”，这其实是很难直接回答的问题。因为每次改动都牵涉模型版本、提示词、工具逻辑三个变量，任何单一指标都很难代表整体效果。我的经验是建一个和实际任务形态一致的回归集。
回归集不用很大，50 到 100 条典型任务即可，但要覆盖三类内容：高频常见请求、边界情况、容易翻车的输入。每次改动后跑一遍回归，记录两个指标：任务完成率和平均轮次。任务完成率反映能力上限，平均轮次反映成本效率。这两个指标一旦有明显回退，改动就是有问题的。
这里有个细节值得提示：不要天天改回归集。回归集追求的是稳定性，频繁变更会让对比失去意义。定期更新是可以的，按月或按大版本更新，但每次评估必须跟上一版本在同一套用例上跑，才能做出可信的结论。
5.3 长期记忆：当前所有方案都还很原始
Agent 的短期记忆依赖上下文，这个部分是有效的；但长期记忆远没有成熟。现在主流的做法是把关键信息抽成结构化条目写入外部存储，下次任务启动时再检索相关片段拼回上下文。这种“记忆外置”方案听上去合理，实际用起来有很多死角。
比如，Agent 很难判断该记住什么。一次对话里有用户偏好、任务中间结果、临时约束，哪些该进长期记忆？处理岔了就会出现未来任务的误判。再比如记忆更新的时机和冲突处理，上一次说“优先使用A方案”，这次说“改成B方案”，Agent 能否妥当地做版本管理？目前大多不能。
所以我对长期记忆的建议很谨慎：不要让 Agent 全自动写读记忆，至少在当前阶段，把记忆的写入动作做成“人工审核或半自动确认”，宁可不记也不能记错。我见过某个团队因为 Agent 记住了一条过期的用户地址，导致整个订单流程出错，这种事故一次就足够让人清醒。
5.4 Agent 的“南北桥”问题：上下文与工具之间的数据总线
计算机里有南桥北桥的概念，它们负责 CPU、内存、外设之间高速传输数据。Agent 也有类似的数据总线：上下文与工具之间的数据交换通道。这里的核心矛盾在于，上下文窗口有限而工具返回数据无限，二者之间的桥梁效率直接决定 Agent 的效能上限。
业界现在逐渐形成了几种做法：工具返回数据先经函数归一化，变成结构化的最小字段集；对超长文本做分块摘要，只保留结论和关键证据；把原始数据落到外部存储，只把“数据索引”和“摘要”放回上下文。这套模式本质上是给数据总线加了一层压缩协议。
我这里特别建议，一切核心工具调用统一走中间层，不要允许模型直连数据库或直调运营接口。中间层是你在 Agent 与外部世界之间建立的安全检查站，既能做参数校验，也能做敏感字段过滤，还能保存审计日志，在三方对接场景里尤其重要。
5.5 多 Agent 协作：分布式系统的第一缕微光
单 Agent 的能力受制于模型和上下文，于是很多人开始尝试多 Agent 架构：一个规划 Agent 负责拆解任务，若干个执行 Agent 负责并行干活，一个验证 Agent 负责结果检查。听起来很美好，但据我观察，当前能跑通的多 Agent 系统，大多是“一个大脑加多个工具”的变体，只是把工具注册从函数扩展成了子 Agent。
评审多 Agent 方案时，我会追问三个问题：子 Agent 之间的数据怎么传递？子任务的结果怎么合并？一个子 Agent 失败会不会拖垮全部任务？如果这三个问题没有明确答案，我建议还是回到单 Agent 加好工具设计上来。
承接主循环的代码设计模式，现在的 Agent 编排逐渐演化出二阶段设计：先规划，再执行。规划阶段用便宜模型生成粗任务列表，执行阶段用主力模型按列表次序逐个完成。这一类模式在稳定性要求高的场景，比“一个 Agent 全包干”要可控得多。用计算机的类比来说，那已经是从单机操作系统走向分布式系统的第一步。
6. 把“新型计算机”落到团队协作与工程化实践里
6.1 从个人实验到团队协同：配置与知识分工
当 Agent 项目由一个人玩转为一个团队协作时，组织方式也需要沿着“计算机分层”的思想重新设计。我们的做法是把角色分成三类：负责业务场景和验收标准的产品，负责工具开发和数据链路的后端，负责提示词、模型选型与评估的算法/AI 工程。三者之间的工作界面就是那份 Agent 配置文件和工具注册表。
这种分层协作，很像传统系统里硬件工程师、系统工程师和应用工程师的分工。你不希望底层 GPU 调度逻辑跑到业务代码里，同样也不希望业务 prompt 逻辑散落在工具函数内部。团队开始按这种方式协作后，Agent 的迭代速度明显加快：业务侧改场景描述不需要动代码，后端新增工具不影响提示词，提示词优化也不阻塞接口开发。
6.2 基建工程远比炫酷演示重要
我给一个新兴团队做架构评审时，他们最自豪的是 Agent 能完成一个很复杂的演示任务：读取多份合同、生成摘要、提取关键日期。但我问了一个问题：如果模型输出突然中断，或者开始的某一步判断错了，你怎么处理？全场沉默。
这就是 Agent 工程与演示 Demo 的分水岭。真正进入生产，你要面对的更多是“模型翻车怎么兜底”“成本超支怎么报警”“用户隐私怎么隔离”。这些内容虽然不酷，但决定了项目能否稳定持续运行。我在所有 Agent 项目里第一优先级都是基建：可观测性、成本控制、权限隔离、失败回滚。这些搞得越早，后续踩坑越少。
6.3 当团队把 Agent 当计算机之后，沟通也顺畅了
一个特别有意思的变化：当我们把 Agent 描述成“一台新计算机”后，团队内部的沟通效率明显提升了。后端说“这个接口返回数据太大，上下文装不下，要做摘要”，产品说“那就像给打印机加装缓存吧”，测试说“工具调用的回归集就是冒烟测试”。所有人都能在同一套类比语言下对齐问题，不再需要用各自陌生的词汇反复解释。
这套沟通方式还能用于向上汇报。向管理层解释“模型选型为什么重要”时，与其说“千亿参数”“推理能力”，不如说“我们团队在选择整台计算机的 CPU，选错了后面所有软件都要重写”。这种表述更直观，更容易引起非技术背景的共鸣。
6.4 从值班助手到更复杂场景的演进路径
值班助手只是 Agent 新计算形态的一个最小切片。在它的基础之上，团队已经把这个架构扩展到更多场景：自动生成周报的“数据梳理 Agent”、跨系统同步信息的“事项中转 Agent”、面向用户的“答疑机器人 Agent”。它们的骨架几乎一样，只是外围设备和感知输入不同。这正是计算机通用性的体现——同一台主机，可以连接不同外设，运行不同软件。
每扩展一个场景，我会要求团队先回答几个硬核问题：任务边界是什么、哪些工具必需、失败时的最低可接受行为是什么。回答清楚的就推进，答不清楚的就砍掉。这种克制让我们的 Agent 项目始终处在“工程可控”的状态，而不是变成一堆无法维护的自动化脚本。
回到开头那个比喻：Agent 是一台新发明的计算机。既然是一台新计算机，它的生态远未成熟，基础设施还非常简陋，很多地方连“汇编语言”阶段都没走到。但这也意味着，现在进场的人有大量的定义权：工具标准、调度方式、记忆机制，这些地基大概率会由正在实践的人一步步打出来。我们眼下能做的，就是清醒地理解它的限制，把每一次尝试都当成对这个新系统的一次配置与优化。
