企业官网建设流程全解析

1. 表面热闹，暗线竞争：为什么Agent Infra是“隐秘战场”

最近连续几个做AI应用的朋友都在跟我聊同一件事：Agent跑Demo很容易，一上量就碎一地。有的卡在多轮对话状态对不上，有的死在工具返回格式不统一，还有的干脆因为日志查不到上下文没法排错。聊到最后都会落到同一个结论——真正决定Agent能不能用的，不是模型本身多聪明，而是底层的Agent Infra（智能体基础设施）靠不靠谱。

标题里“巨头的隐秘战场”这个说法，我一开始觉得有点夸张，但看了越来越多真实团队踩的坑之后，我承认这个判断基本准确：模型能力决定了Agent的上限，Agent Infra决定了它到底能跑多远、跑多稳、花多少钱。用户看到的是机器人自动填单、自动查库、自动回复，看不到的是背后那一堆循环控制、记忆、工具、评估、可观测和成本体系。这一点恰恰就是“隐秘战场”的由来——仗打得激烈，但围观群众看不见。

这篇文章要聊的，就是这个战场到底在争什么，以及一个普通工程师为什么、从哪里能拿到入场券。不吹概念，不堆术语，我会把Agent Infra按层拆开，讲清楚每一层在解决什么问题，再结合一套最小可用Demo的实操过程，把排查链路和工程取舍一起说透。

1.1 热闹在Agent应用，战果在地基

Agent应用这几年给人的感觉是“百花齐放”：有做客服助手的，有做代码助手的，有做数据分析助手的，还有做内部流程自动化的。但凡是真正落地超过三个月的项目，都会撞上同一堵墙——如果只是把大模型往外一包，用Prompt拼几个工具调用，那么功能一多，系统就会开始出现各种“智力正常但行为失控”的场面。

举个最典型的例子：你希望Agent帮用户查天气的同时预订会议室，它可能要连续调用两个工具。第一个工具返回的结果格式稍微有偏差，第二个工具就无法继续。模型本身没问题，错的是中间那层没有被认真设计的“转换器”。再比如，用户连续问了五轮关于上月销售额的问题，Agent居然把第二轮的筛选条件带到了第五轮的回答里。这不是模型变笨了，是会话状态没有管理好。

这层基础设施过去是没人看重的“脏活累活”，现在成了最抢手的地基。为什么？因为Agent的核心能力全在“外部系统交互”上，而不是模型内部的单次推理。一次推理再准，也没办法保证一百次串行调用之后，结果仍然是准的。地基层解决的就是这些“准不准、稳不稳、贵不贵、能不能回溯”的问题。

1.2 为什么巨头都“躲”着打这张牌

既然是必争之地，为什么又说它是“隐秘战场”？三个原因叠在一起，让它显得格外低调。

第一个原因是技术底子不够性感。和“发布新模型刷分”“放出惊艳Demo”相比，“我们把工具调用的错误率降到了0.5%”“我们让记忆模块的召回延迟降了40%”这类成绩很难上头条。但对客户来说，后者的体感远比前者强烈。第二个原因是这套东西要跟具体业务长年累月磨合，谁家都有自己的血泪经验，轻易不会公开分享。你要真去打听某家大厂内部是怎么做Agent可观测的，大概率只能听到“我们有内部平台”这么一句。第三个原因是，Agent Infra的布局往往和模型、数据、云资源绑在一起，属于战略筹码。谁掌握越多的运行时控制权，谁就越能决定未来上层应用的玩法和分成方式，所以细节不随便对外讲。

这种“躲着打”的状态不会一直持续。可以预判的是，未来半年到一年，各家会把Agent Infra的能力逐渐产品化，以托管服务或开源框架的形式放出来。到那时候，普通人能接触到的材料和工具会更多，但也意味着窗口期在收窄。现在自己动手把底层逻辑搞清楚，比到时候追着别人的文档跑要划算得多。

1.3 协议与标准正在收敛，中场反而更挤

以前做工具调用，每个框架都是自己一套写法，张三的Agent接不了李四的工具，李四的工具接不了王五的知识库。这种割裂让开发成本居高不下，也让“统一标准”变成了一个大机会。社区里已经出现了一些收敛趋势：工具接口定义越来越像，会话消息结构越来越像，记忆存取的方式也越来越像。

这不是坏事。标准收敛意味着普通工程师学习成本降低，不必再被绑定在某个特定框架里。但硬币的另一面是，巨头和开源社区基于标准做出来的托管平台会越来越同质化，最终比拼的不再是谁的接口更顺手，而是谁的地基更扎实——谁的记忆管理更省token、谁的可观测体系能定位到“哪一轮决策错了”、谁的工具沙箱更安全。

对工程师来说，这种“中场拥挤”恰恰是好消息：架构正在定型，但很多细节还没有完全长出来。你现在看准一个细分方向踩进去，等平台成熟时，你已经带着一套实战经验在那里等了。

2. 把Agent Infra拆开看：实际在争哪几层

要进场，先得知道战场有多大。按我自己的经验，可以把Agent Infra分成五个核心层：运行时与控制流、记忆与状态、工具与集成、可观测与评估、安全与治理。每层解决的问题不同，技术难点也不同，但它们是咬合在一起的。

下面把每层展开讲一下，这样你才能知道“工程师入场券”到底该插进哪个门锁。

2.1 运行时与控制流：这是一个循环，不是一个Prompt

很多刚开始做Agent的人有个误解：以为Agent就是把用户问题丢给大模型，拿回答返回。实际上，完整的一个Agent循环至少包含四步：接收任务、模型决策、执行工具调用、把结果回填给模型，然后继续下一轮，直到模型给出最终答案。

这个循环听起来简单，工程上却全是细节。首先是“重试”：工具调用偶尔会失败，网络抖动、接口超时、权限过期，哪一类都可能导致任务中断。你需要在循环里设计“最多重试几次”“一次工具执行多久算超时”“失败之后是换个方案还是直接告知用户”。其次是“恢复”：如果Agent在第五步崩了，能不能拿到断点，从第五步继续跑，而不是让用户从头再描述一遍。再就是“人工介入”：某些风险操作不能直接让Agent自主执行，需要插入人工确认节点，这一步怎么做才不会把循环卡死。

为什么这条线重要？因为任何一个小环节没考虑，线上就会出大事故。我自己见过一个所谓的“智能工单分类”Agent，因为重试策略写得太简单，工具返回异常后它反复重试，生生把一个几秒钟的任务拖成了几分钟。所以现在很多团队的共识是：先把循环控制写稳，再谈模型调优。

2.2 记忆与状态：上下文不是越多越好

大模型有上下文窗口上限，也就是它一次“看”得进多少信息。Agent在运行时会出现两类记忆需求：一类是工作记忆，比如当前任务已经做完哪几步、下一步还剩什么；另一类是长期记忆，比如用户的偏好、部门名称、历史工单结论。

多数团队早期会图省事，把所有历史消息一股脑塞进上下文。一开始还好，消息一多马上出事。轻则token成本暴涨，重则模型被淹没在无用信息里，把早先的错误结论当成正确答案。另一个常见问题是状态丢失：用户说“改成上周的方案吧”，Agent如果记不住“上周的方案指哪份文档”，整个对话就断了。

这一层的工程思路，简单说就是“分层存取”：工作记忆用窗口裁剪，只保留最近几轮消息；长期记忆用外部存储，按需要检索；上下文要定期做摘要压缩。每一个策略背后都有取舍，这也使得记忆与状态成为Agent Infra里极有深度的方向。

2.3 工具与集成：Agent身上的手脚

Agent真正能干实事，靠的是工具。所谓“工具”，本质上是一个个有输入输出定义的函数：查天气、建工单、发邮件、读数据库。模型的责任只是“决定调用哪个工具、填什么参数”，真正的执行发生在工具层。

这一层的核心是定义清楚。每个工具都要像API一样有明确的名称、描述、参数类型和返回格式。如果工具描述写得含糊，模型就会反复猜测；如果返回格式不严格，模型就可能把“1”理解成布尔值，把“22.0”理解成字符串，进而导致后续决策连环错。更现实的问题是权限，工具一旦能发邮件、能删文件，就必须有严格的鉴权和审计。这也是很多企业不敢直接把Agent放给全员使用的原因之一。

工具层的另一个重点是“统一接入”。不同系统有不同的协议、鉴权方式、数据格式，Agent不可能为每一种都写死一套逻辑。现在社区讨论比较多的思路是“工具即标准接口”，有点像把各种充电口统一成了同一个USB-C接口。方向是对的，但落地还需要时间。无论标准最终长成什么样，学会把任意能力封装成结构化的工具，是Agent开发的基本功。

2.4 可观测与评估：没有评估，Agent就是黑盒

传统软件上线前有单元测试、集成测试、回归测试，Agent却很难沿用这套逻辑。为什么？因为Agent的“输出”不是一串确定的字符串，而是一长串决策轨迹：它调用了哪些工具、为什么这么选、中间有没有绕路。不同次数执行同一个任务，路径可能完全不同。

这意味着，只测“最后答没答对”是远远不够的。更关键的是测“决策过程是否符合预期”。比如某项任务应该一步完成，结果Agent多绕了三个工具，虽然结果对了，但成本高了十倍。再比如某个工具本来不该出现在这个场景里，Agent却贸然调用了。这些都是局部指标，需要把整个过程记录下来。

评估也要分两个层次：一是单轮效果，比如工具选择准确率、参数填充正确率；二是完整任务的成功率，比如用户问题最终有没有被解决。很多团队会把前一步收集的数据沉淀成离线回归集，每次改prompt、换模型、改框架都跑一遍，防止“修好东边拆了西边”。这其实就是Agent世界的CI/CD。

2.5 安全与治理：不出事就是最大的竞争力

安全在Agent Infra里经常被放在最后，但恰恰是它最容易决定一个产品能不能进企业。Agent如果只有对话能力，风险还可控；一旦它拥有读数据库、发邮件、改配置的权限，风险等级立刻上升到业务级别。

安全治理要回答几个问题：Agent拿到的最小权限是什么？它调用的工具可不可以被沙箱隔离？每次调用有没有审计日志？用户提交的数据是否会被用于模型训练？如果模型被诱导说出不该说的话，或是被提示词注入攻击骗去调用高危工具，系统如何阻断？

这些问题没有标准答案，但都有通用原则：默认拒绝，能给只读权限就不给写权限；高危操作必须经过人工确认；全部调用过程留痕可回溯。真要在Agent Infra这条路上长期走下去，安全意识不是附加值，而是准入门槛。

3. 工程师的入场券：从哪一块切入最划算

前两年入局AI应用，大家拼的是“谁先做出个能聊天的玩意”；现在再入局，拼的是“谁能在Agent Infra这个地基里找到一个别人还没占住的螺丝位”。说得直白点，这张入场券不再是“我会调大模型接口”，而是“我能让Agent在真实场景里持续可靠地干活”。

3.1 先认清位置：不是每个团队都要自建全套

听到“基础设施”四个字，很多人下意识觉得这是大厂才玩得起的东西，个人和小团队没戏。这个判断错得离谱。自建全套Agent Infra当然重，但入场不等于自建全套。大多数工程师真正需要的是：理解这套系统的设计逻辑，然后在一个垂直场景里把一个环节做出价值。

比如你所在部门天天要用Agent处理工单，你就可以围绕“工具与集成”这一层做一套封装，让同事不用关心底层模型差异，直接接入内部系统。再比如你在的小组总抱怨Agent答非所问，你就可以从“记忆与状态”切入，先诊断上下文管理策略，再做一套精简方案。这种改进虽然不像发布新框架那么有面子，但它直接解决业务问题，价值肉眼可见。

我判断的方向是，开源框架会负责把“通用底座”做好，普通工程师的机会在于“把通用底座接进具体业务”，并在这个过程中发现底座本身的不足，再反哺给开源社区。这才是普通人和巨头交手的不对称优势——巨头掌握平台，你掌握场景细节。

3.2 三条最值得走的技术路线

如果你现在还在犹豫往哪发力，我建议你从三条路线里选一条深入：

第一条是“场景型地基工程师”。不追求自己发明底层框架，而是熟练使用某个成熟的开源Agent框架，专注于把企业内部系统接入Agent。这条路对业务理解要求高，但见效最快。第二条是“评估与可观测专家”。这条路线目前极度缺人。大多数团队连“Agent行为对不对”都说不清楚，谁能先把评估体系和追踪能力建立起来，谁就能抢占话语权。第三条是“记忆与状态方向”。这是Agent Infra里最脏最累但也最值钱的部分，谁解决了跨会话记忆可靠性的问题，谁就把Agent的体验带到了一个新高度。

A同学的经历很适合当例子。他之前在一个内部项目里负责给Agent加外部记忆，最初只想做个简单的向量检索，后来发现真正的难点不是“查得快”，而是“什么时候该把记忆写进去、什么时候该把它清掉”。他把这个问题拆成了三个小步骤：记忆写入策略、冲突处理、摘要更新，前前后后跑了两个月，最后把一次业务问答的准确率从65%提到了85%。

3.3 一个可行的三个月路线图

入门路线不要贪多。我自己推荐一个相对可行的“三个月计划”，适合大多数有基础后端开发经验的工程师：

第一周，手写一个极简Agent循环，不依赖任何框架，只实现“模型对话-调用工具-继续对话”。目标是搞清楚循环的本质。第二到第四周，给这个循环加上两层东西：一层是简单的滑动窗口记忆，另一层是三个自定义工具。第五到第八周，把一个开源Agent框架部署起来，尝试替换或扩展它的存储模块、评估模块。这一步会真正逼你读别人的源码。第九到第十二周，选择一个垂直场景做端到端落地，比如“自动归类用户反馈并生成摘要”，同时把性能指标和成本指标记录下来，写成复盘。

这个计划能不能做完，比做得多漂亮重要。哪怕最后只完成了一半，你也比那些只看不练的人领先一大截。因为你对“Agent是怎么在真实系统里工作的”有了第一手感知，而这种感知没法靠刷文档获得。

3.4 作品和简历上真正值钱的东西

想靠Agent Infra拿offer，简历上最值钱的不是写了句“熟悉Agent原理”，而是三个能证明你要点的东西。第一，你修过一个真实的Agent故障，并且能复盘完整排查链路；第二，你搭过一套哪怕很简陋的评估或追踪系统，有“成功率”“工具调用准确率”“平均token消耗”这些实际数字；第三，你做过一次“让Agent从不可用变得可用”的优化。

这三个值钱点的本质是：你不是在消费Agent，而是在建造Agent。面试官最怕遇到那种只会在Demo里玩一下的人，你只要拿出任何一个环节的系统性改进证据，就已经比大部分人走得远了。

4. 手把手：一个“最小可用Agent Infra”怎么搭起来

讲再多理论，都不如动手跑一遍。我在这里带你从零写一个最小但完整的Agent基础设施，核心不依赖重框架，只用一个大模型客户端的统一封装和几个工具。整个架构只有三层：循环控制、工具服务、记忆管理。

4.1 架构形状：把Agent看成一个“带工具的循环”

理解Agent Infrastructure，最重要的一步是建立“循环”的心智模型。我们不要把它想象成什么智能体平台，就把它想成一个工厂流水线：模型是老师傅，负责看情况喊谁来干活；工具是工人，每一个只干一件事；记忆是白板，写着现在干到哪了、刚才出了什么结果。

用户输入 -> 组装消息 -> 模型决策 -> 有工具调用？ -> 执行工具并回填 -> 再次模型决策 -> 输出最终答案 ^_________________|

上面这段逻辑用文字描述就是这样：只要模型输出的不是最终答案，而是一个“我想要调用某工具”的结构，系统就执行该工具、把结果追加到消息末尾，再让模型继续决策。这个流程最多重复N轮，防止陷入死循环。

4.2 核心代码骨架：循环、工具、消息组织

下面这个Python版本足够跑通最小闭环，重点是让你看到“基础设施”并不是什么玄学，它就是非常朴素的工程代码：

from dataclasses import dataclass, field from typing import Callable, Any @dataclass class ToolSpec: name: str # 工具唯一标识，要求小写英文字母 description: str # 给模型看的说明，必须说清“什么时候用” parameters: dict # JSON Schema，描述每个参数的类型和含义 fn: Callable # 真正执行的函数 @dataclass class AgentRuntime: model_client: Any # 统一封装的大模型客户端 tools: list[ToolSpec] max_rounds: int = 10 history: list = field(default_factory=list) def add_tool(self, tool: ToolSpec): self.tools.append(tool) def run(self, user_input: str) -> str: self.history.append({"role": "user", "content": user_input}) for _ in range(self.max_rounds): response = self.model_client.chat( messages=self.history, tools=[t.to_schema() for t in self.tools], ) if response.tool_calls is None: final_answer = response.content self.history.append({"role": "assistant", "content": final_answer}) return final_answer self.history.append({"role": "assistant", "content": None, "tool_calls": response.tool_calls}) for call in response.tool_calls: result = self._dispatch_tool(call["name"], call["arguments"]) self.history.append({ "role": "tool", "tool_call_id": call["id"], "content": str(result), }) return "reach max rounds, give up" def _dispatch_tool(self, name: str, arguments: dict) -> Any: for tool in self.tools: if tool.name == name: return tool.fn(**arguments) raise ValueError(f"unknown tool: {name}")

这段代码有几个关键设计值得展开讲。

第一，max_rounds为什么默认10而不是无限？因为大模型在工具调用阶段可能陷入“反复选错工具”或者“选了工具但参数一直填不对”的循环，不设上限，一次任务会把token账单烧穿。第二，工具的执行结果必须统一str(result)回填，因为模型收到的消息体要求内容是文本。很多初学者在写工具时直接返回一个dict，模型会看得很吃力，格式一乱，后续决策立刻偏差。第三，消息历史里明确区分了“assistant的决策内容”和“tool的返回内容”，这种结构化记录是一切可观测性的基础。

4.3 记忆层：滑动窗口加上下文摘要

最小Demo里，记忆层不需要引入向量数据库，先做两件事就够了：最近的N轮原始消息完整保留，更早的历史统一压缩成摘要。原理很朴素：模型离现在越近的信息记得越清楚，太久远的细节靠摘要保留大概方向。

def build_context(history, recent_window=6): if len(history) <= recent_window: return history recent_messages = history[-recent_window:] older_messages = history[:-recent_window] summary_prompt = ("请用两句话概括这段对话的关键背景：" "已完成步骤、当前目标、用户偏好") summary = model_client.chat( messages=[ {"role": "system", "content": summary_prompt}, {"role": "user", "content": json.dumps(older_messages, ensure_ascii=False)}, ] ).content return [ {"role": "system", "content": f"历史摘要：{summary}"} ] + recent_messages

为什么这样设计？直接截断会把前面已经确定的信息丢掉，比如“用户的上游系统是A”这种关键背景；全部保留又会浪费上下文窗口，还容易让模型注意力被无关的旧消息带偏。折中方案是“摘要+窗口”，这样每轮对话模型既知道“全局大概在做什么”，又能看到“最近具体聊了什么”。

这套方案当然不完美，它没有解决长期记忆的跨会话持久化问题。但在一个最小可用的Demo里，它足以让Agent看起来“像是有记忆的”。如果你想继续往下做，把summary和recent_messages写入外部存储，在下次会话开始时重新加载，就实现了一个最朴素的记忆系统。

4.4 第一道验证：把指标变成门槛

最小Demo跑起来还不够，要让它真正像“基础设施”，你得在上面加一道最基本的评估闸门。最简单的方式是准备一个固定问题集，跑完后统计两个数字：任务完成率和平均工具调用轮数。

def evaluate_agent(runtime, cases): success_count = 0 total_rounds = 0 for case in cases: output = runtime.run(case["input"]) ok = all(kw in output for kw in case["expected_keywords"]) if ok: success_count += 1 total_rounds += runtime.max_rounds return { "success_rate": success_count / len(cases), "avg_rounds": total_rounds / len(cases), }

这套评估相当简陋，但它的价值在于可以沉淀成一个回归集。以后你改记忆策略、换模型、调整工具描述，都先把这组数据再跑一遍。如果成功率掉了五个点，立刻就能发现。很多人做Agent不做回归评估，导致今天加了一个功能，昨天修好的问题又回来了。这个简单脚本就是预防“修东坏西”的起点。

5. 真实踩过的框架坑：排查链路与工程化取舍

只看最小Demo，你会觉得Agent Infra不过如此。但真实项目里，意外永远藏在“边界情况”。我把三个自己踩过的坑写出来，每个都带上完整的排查思路，而不是直接给结论，因为那种“出问题→改配置→解决”的叙事对实际工作没有帮助。

5.1 案例一：工具返回格式不严格，Agent陷入死循环

现象：某个流程Demo在跑“查询客户订单”的任务时，同一个工具被模型连续调用四遍，但模型始终得不到“满意”的信息。日志里可以看到模型每次都说“我还需要确认订单状态”，而工具返回值里明明已经有状态字段。

排查过程：我先看消息历史里工具返回的原文，发现工具函数返回的是一个Python dict，字段名是status，值是一个浮点数。而工具schema里把status声明成了字符串。模型严格按schema校验，发现22.0跟“22”对不上，于是认为结果不可用，继续发起查询。修复方案很快清晰：在_dispatch_tool里对所有返回值做严格类型规范化，该转字符串转字符串，该保留数字就定义成数字类型；同时在工具schema的说明里加一句“返回值为数字时，直接原样返回，不要加单位”。

这个坑的教训是：工具返回格式的严格程度，直接影响模型后续决策的稳定程度。你随手写的一个类型瑕疵，到了模型那里会变成一种“隐性不确定性”，而模型为了消除不确定性，会选择不断重试。

5.2 案例二：记忆污染，前一轮的错误被带到第三轮

现象：用户问一个数据分析任务，前两轮All good，到第三轮Agent突然把第二轮的某个临时结论当成用户确认过的事实，结果答案明显偏离。

排查过程：我把消息历史完整导出，发现第二轮的临时结论被Agent自己追加了一条assistant消息，而这条消息随后在设计很粗糙的“历史全量拼接”里变成了下一轮模型的已知条件。问题不在模型理解力，而在记忆层的“写入策略”太粗糙：它没有区分“事实”和“假设”。修法是给消息分两类：一类是用户明确确认过的最终事实，另一类是过程中的临时状态。只有前者允许进入长期记忆，后者只保留在工作窗口里，窗口滑出后即被清除。

这个坑很典型，它说明记忆层不只是“存下来”那么简单。存什么、不存什么、什么时候清理，才是真正决定记忆系统可靠性的关键。这也是为什么我说“记忆与状态”方向值钱，因为做得好的团队实在太少了。

5.3 案例三：成本失控，一次简单任务花了二十次模型调用

现象：同一类任务，模型经常“导致”一次调用三四个工具才能完成，整体token消耗比预期高出一倍。从用户视角，结果没错，但成本明显不健康。

排查过程：我给每个工具调用打上计数标签，发现大头不在模型本身，而在“无谓重试”。有些工具确实会偶发超时，系统默认重试三次，而Agent在重试期间还会继续追问模型，每次追问都是一次完整的模型调用。修法分三层：工具内部增加本地缓存，相同参数直接返回历史结果；超时重试改成语义更友好的“重试前先告诉用户”；对简单任务启用“快模型”做工具决策，只在复杂任务上用强模型，最终成本降了40%。

这里想强调的是，成本优化绝不是一句“换个更便宜的模型”这么简单。它要求你对整条调用链路有量化认知：哪些调用是必要的，哪些是多绕的，哪些是重试导致的。这也是“可观测性”直接变现的一个场景。

5.4 自建、开源还是托管：一张决策参考表

很多人会纠结“到底该用开源框架还是花高价买托管平台”。我的建议是分情况，别拍脑袋。如果业务场景简单、数据不敏感、团队规模小，直接用托管服务效率最高；如果业务有大量自定义流程，或对数据合规要求高，则应在开源框架上做二次开发；如果团队已经发展到开始关注成本、可观测性、安全这些硬指标，再考虑自建关键模块。

决策时最贵的成本往往不是工具费用，而是“切换成本”。所以一开始就别把方案选死，尽量选迁移成本低的方式。比如工具层按标准schema封装，将来从开源切到托管，工具本身不用重写。这种“抽象隔离”的思路，在Agent Infra里比任何具体技术都更重要。

6. 写在最后：普通工程师个人经验谈

在我自己动手把这一整套跑通之后，最大的体会是：Agent Infra没有神秘公式，它就是把软件工程里那些最朴素的原则——模块化、可观测、可测试、安全边界——重新应用到一个新对象上。这个新对象不再是一台“确定性的计算机”，而是一个“概率性的协作系统”，所以原来那套“写完就没问题”的思维必须丢掉。

如果你现在手里只有一张入场券，我建议你把它用在两个地方：第一，搭建一套哪怕是手写的评估回归，确保Agent每次改动都有依据；第二，亲手处理一次记忆或工具调用的故障，把排查链路完整写下来。这两个动作会逼你看到Agent系统的真实纹理，也会成为你和同行交流时最稀缺的经验资产。

最后分享一个实用技巧：开发阶段不要一上来就接强模型做所有决策，先用“快模型+详细工具描述”把流程磨通，再逐步换成强模型做对比。这样既能控制开发成本，也能让你一眼看出“某些错误到底是模型能力问题，还是基础设施设计问题”。Agent Infra的价值，恰恰就在于当你想换模型时，发现一切都还稳稳地站在原来的地基上。