企业官网建设流程全解析

最近跟同行聊技术选型，十个里面九个都在提 agent-native。这个词从去年开始频繁出现在各种 AI 工程讨论里，但真正能把它讲清楚的人并不多。很多人把"用了大模型 API"就叫 agent-native，也有人把它等同于"写个 ReAct 循环加几个工具函数"，这两种理解都太窄了。我在重构一个内部数据运维工具的时候，完整地把架构从"AI 辅助"切成了"Agent 优先"，踩了不少坑，也理清了不少思路。这篇东西不是概念科普，是我基于实操对 agent-native 的拆解：它到底改变了什么、落地时哪些设计最关键、以及那些文档里不会写的坑。

如果你正在做 AI 应用，或者准备把一个传统系统改造成"能自己干活"的形态，这篇文章应该能给你一些参考。我会按照"概念辨析-架构设计-代码落地-避坑经验"的顺序来讲，尽量说人话，把工具选型、参数配置、方案取舍背后的理由也一并讲透。

1. agent-native 到底在说什么：从 AI-native 到 agent-native 的演进

1.1 先厘清概念：什么才算 agent-native

我说一个自己的判断标准：一个系统是不是 agent-native，不取决于它有没有调用大模型，而取决于模型驱动的决策是不是系统的主流程。

传统软件是"代码定义逻辑，模型提供能力"。比如你做个人力资源系统，里面有个智能招聘助手，模型只是做简历解析、问答、评分，真正的流程——谁该进入面试、下一步推给谁、状态怎么流转——全是代码写死的。这叫 AI-native，AI 是嵌在系统里的一个组件，而不是系统运行的引擎。

agent-native 则完全是另一套逻辑。系统的主流程不是预设的 if-else，而是"把目标交给 agent，由 agent 通过推理决定下一步动作"。代码定义的不再是流程，而是 agent 的能力边界和可用工具。比如同样是招聘系统，agent-native 的架构是：agent 收到"帮我筛掉不符合硬性条件的人"这个指令，它自己去调用简历解析工具、去查岗位要求、去对比打分，甚至自己发现"这家公司某些岗位要求本科学历但 JD 没写"这种隐含信息，再决定要不要追问 HR。

这中间的差别是本质性的。传统方式里，系统的智能来自开发者的预判——你把所有可能的情况都枚举出来，模型只是在枚举结果里面做映射；而 agent-native 的智能来自模型本身的推理能力，开发者放弃了对过程的完全控制，只保留了对目标、边界和工具的管控。所以说 agent-native 是一场架构风格的迁移，不是加几个接口就完事。

1.2 为什么现在突然火起来

其实 agent 这个概念在学术界存在很多年了，从早期的 BDI 模型到后来的强化学习智能体，一直有研究。但过去大家不叫它 agent-native，因为它实装不了——模型推理能力不行，工具调用不稳定，上下文一长就丢失信息。你设计了一套很漂亮的智能体架构，跑起来发现模型经常误解工具参数、自己绕圈子，最后还不如写死流程。

现在这个局面被几个技术进展改变了。第一，长上下文能力大幅提升，模型可以在一次会话里携带更多状态和工具定义，不再需要频繁的外部存储来搬运记忆；第二，结构化工具调用（function calling）成熟了，模型不再是"生成一段文本让你去解析"，而是直接输出一个规范化的调用意图，这在工程上省掉了大量文本解析的脏活；第三，推理模型的成本在快速下降，过去让模型"多思考几步"烧钱烧到心痛，现在可以承受。

还有一个容易被忽略的因素是评估体系的进步。以前没人敢把核心流程交给模型，因为没法量化它干得好不好。现在有了轨迹评估、回归测试集、沙箱验证这些手段，至少能在上线前知道模型在哪些场景里会翻车。这几个条件凑齐，agent-native 才从论文里的概念变成了工程上可行的方案。

我做那个数据运维工具的时候，最初也是打算"模型 + 规则引擎"的混合模式——规则负责流程，模型负责生成。后来试了试纯粹把决策权交给 agent，只保留最底层的安全拦截规则，效果反而好了很多。这个体验让我彻底转了向。

2. agent-native 架构的关键设计

2.1 核心单元变了：从函数到能力

传统架构里，系统的核心单元是函数或服务，你用接口定义输入输出，用调用关系定义数据流。agent-native 架构的核心单元是"能力"——一个能够被 agent 理解并调用的动作，它不再是简单的方法签名，而是包含意图描述、参数 Schema、约束条件、失败模式的一组元数据。

打个比方，传统系统像一条流水线，工件从 A 传到 B 再到 C，顺序是固定的；agent-native 像你请了一个带工具箱的实习生，你告诉他"今天把这些零件加工完"，他自己决定先用扳手还是先用螺丝刀，遇到卡住了还会停下来问你。

在工程上，这个转变对工具注册表的设计提出了很高要求。我见过不少团队把工具做成"越细越好"，认为给 agent 提供更原子化的能力它就能更精准地组合——实际上模型对这种细粒度工具的理解能力有限。工具粒度的权衡很重要：太粗的功能，比如"execute_sql"，模型不知道具体表和字段，容易胡来；太细的原子操作，比如"take_screenshot"、"parse_html"，模型又很难在复杂的意图里编排它们。实操中比较稳妥的做法是把工具设计在"人类工程师能直接理解并执行"的粒度。如果一段说明文字让工程师一看就知道该怎么干，那这个工具粒度基本就是对的。

工具数量也要克制。模型在每一步推理中都需要把工具定义放进上下文，工具越多，注意力就越分散，错误率明显上升。我实测过，一个任务上下文中同时出现的工具超过 15 个之后，模型选错工具的概率会翻倍。超过这个数量就要做分层，把工具分类，让 agent 先选类再选具体工具。

2.2 上下文优先：把状态交给模型

传统应用的状态存在数据库里，存在 Redis 里，代码通过查询把状态读出来做计算。agent-native 完全不同——agent 的大部分状态就是上下文本身。模型读过什么、记住什么、决定什么，都是对话上下文的一部分。这意味着上下文工程不再是"提示词技巧"，而是核心系统设计。

我自己总结了一套上下文管理的分层方法，核心是区分"持久事实"和"过程记忆"。持久事实是业务数据，比如库存数量、用户权限、订单金额，这些必须放在外部的数据层，需要时通过工具查询；过程记忆是 agent 推理过程中的中间结论，比如"用户似乎更关注性价比"、"上次尝试了方案 A 因为数据不足而失败"，这些放在上下文里。错误的做法是把所有数据一股脑塞进上下文——上下文越长，模型越容易在早期信息上遗忘，token 成本也线性增长。

系统提示词的结构也有讲究。我给 agent 写的 system prompt 固定分四个部分：身份和目标、能力边界（明确什么不该做）、工具使用规范（遇到什么情况用什么工具，遇到什么情况需要追问用户）、输出格式要求（结构化输出的约定）。能力边界这一块很多人会忽略，但不写清楚，agent 就会在越界边缘试探。比如我的数据运维工具，我会明确写"不要直接删除线上数据，如需删除必须先列出影响行数并请用户确认"。

上下文还有一个非常实际的问题：一轮任务跑下来，中间过程产生的临时内容会污染下一轮任务的判断。我现在的做法是设计一个"会话压缩器"，当上下文的 token 数超过预设阈值时，把中间过程压缩成结构化摘要，只保留结论、已尝试的动作和遗留问题。这个压缩器本身是一个较小的模型调用，成本很低，但能把上下文里的垃圾清干净。

2.3 工具边界与 MCP 的意义

工具调用是 agent-native 架构的物质基础，没有工具的模型只是聊天机器人。但我观察到很多团队在接工具时走了弯路：每一个项目都要为每一种工具写一套连接代码，连接逻辑和业务逻辑纠缠在一起，调试痛苦，复用基本为零。

MCP（Model Context Protocol）就是在这个背景下出现的开放协议，目的是统一"模型-工具"的连接方式。你可以把它理解为工具界的 USB-C 接口——以前每个设备要配自己的线，现在只要设备支持这个标准协议，插上就能用。MCP 定义了工具发现、工具调用、资源读取这些标准动作，让 agent 框架、API 网关、各种外部服务之间有了统一的对话语言。

我在项目中实践下来，MCP 最大的价值不只是省了重复代码，而是把"工具边界"显性化了。通过 MCP 接入一个数据源，你要写清楚它暴露哪些能力、每个能力背后的权限和约束、调用后返回什么内容。这个描述过程本身就是一次系统安全边界的梳理。我在接入内部监控系统时，就是通过定义 MCP 服务把"只读权限"焊死在协议层，agent 想改监控配置也调不到对应能力。

当然，MCP 也有我觉得做得不够好的地方：调试工具还不算成熟，链路一长，出了问题要排查协议层还是工具层，费不少劲。但方向是对的，值得在项目里引入。

3. 实操落地：从零搭一个 agent-native 应用

3.1 最小闭环怎么搭

讲完了设计和思路，下面上点实际的东西。很多人学 agent-native 从 LangChain、LangGraph 这类框架入手，框架确实能帮你省去很多样板代码，但我觉得作为工程师，第一遍最好还是手写一个最小闭环。手写一遍才能理解框架里那些抽象到底在解决什么问题，出了问题也知道去哪里排查。

最小闭环很简单：一个带工具调用循环的对话系统。核心思路是——模型看到用户请求，如果它判断需要调用工具，就输出一个结构化的调用请求；你的代码执行这个请求，把结果返回给模型；模型再基于工具结果做下一步推理，决定是继续调用还是给出最终答案。这个循环一直持续到任务完成。

我用 Python 写一个极简版本给你看，你可以直接跑通：

import json from openai import OpenAI client = OpenAI() # 按你的实际网关配置 base_url 和 api_key # 1. 定义工具能力 def get_city_weather(city: str) -> str: """模拟查询城市天气，实际场景请替换为真实 API 调用""" mock_data = { "北京": "晴，18°C，风力3级", "上海": "小雨，22°C，风力2级", "深圳": "多云，26°C，风力1级" } return mock_data.get(city, f"暂无{city}的天气数据") # 2. 工具注册表：告诉模型有哪些工具可用、如何调用 TOOL_REGISTRY = [ { "type": "function", "function": { "name": "get_city_weather", "description": "查询指定城市的当前天气情况，返回气温和天气现象描述", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如：北京" } }, "required": ["city"] } } } ] def run_conversation(user_message: str, max_steps: int = 5) -> str: messages = [ {"role": "system", "content": "你是一个本地生活助手。查询天气时务必使用工具，不要凭空编造数据。"}, {"role": "user", "content": user_message} ] for step in range(max_steps): response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=TOOL_REGISTRY, # 把工具注册表传给模型 tool_choice="auto" # 让模型自己决定是否调用工具 ) message = response.choices[0].message # 情况一：模型没有要求调用工具，直接返回最终答案 if not message.tool_calls: return message.content # 情况二：模型要求调用工具，我们把请求追加到上下文，然后执行工具 messages.append(message) for tool_call in message.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) if fn_name == "get_city_weather": result = get_city_weather(**fn_args) else: result = f"未知工具: {fn_name}" # 把工具执行结果以 tool 角色的消息返回给模型 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) # 下一轮循环，模型会看到工具结果并继续推理 return "已达到最大执行步数，任务未完成，请检查工具链路。" # 3. 测试 if __name__ == "__main__": answer = run_conversation("北京和深圳今天天气怎么样？") print(answer)

这段代码里最关键的设计是第 36 行到第 60 行的循环。模型输出的 tool_calls 不是直接执行的指令，而是"调用意图"——你必须把它以 assistant 角色消息追加回上下文，再以 tool 角色消息返回结果，模型才能"意识到"执行已经发生。很多人第一次写这段代码会把消息顺序搞乱，导致模型以为自己还在幻想阶段，编造工具结果。

3.2 参数选择与 ReAct 模式的逻辑

上面例子里有两个参数需要解释一下。一个是tool_choice，我用的"auto"表示模型自主决定要不要调用工具。还有一种"required"表示强制模型必须调用工具，这在某些需要保证数据真实性的场景里有价值——比如你不希望模型在没查询数据库的情况下就回答用户的业务问题。另一个是max_steps，我设成 5，这是对模型循环次数的硬约束，防止 agent 陷入无限循环烧钱。

这个循环本质上就是学术界讲的 ReAct 模式——Reason + Act，先推理再行动。模型先分析用户意图，规划一个动作，执行后观察结果，再根据结果调整计划。普通人解决复杂问题也是这个流程：先想，再做，再根据反馈调整。agent-native 应用之所以能对付真实世界的多变场景，靠的就是这个循环，而不是预设分支。

实践中有个容易忽略的细节：工具函数返回的结果字符串不要太长。模型是把整个工具结果塞进上下文再推理的，如果你返回一个几万行的 CSV，后续每一步推理都会被这段大文本拖慢，token 成本飙升。正确做法是在工具内做好预处理，只返回模型决策需要的信息。我的习惯是让工具返回"摘要 + 关键明细"，比如 SQL 查询工具返回总行数、前 20 条样例和汇总统计，而不是原始数据集。

工具失败的处理也要提前想好。工具调用什么情况下会报错？参数类型不对、外部服务超时、依赖数据缺失，这些都要在工具内捕获并返回结构化错误信息，让模型"知道"这次调用失败了，最好还带上失败原因。如果让异常直接抛出到主循环，agent 就失去了自愈的机会。我见过一个很好的实践是在错误信息里附上"建议做法"，比如"查询超时，可以缩小日期范围后重试"，模型看到后会主动调整参数再试一次。

3.3 多智能体协作怎么拆

单个 agent 做不了所有事，复杂系统还是要拆。但拆多智能体是有代价的：每个 agent 之间要传递上下文，必然产生信息损耗；多一个 agent 就多一层决策不确定性。我的经验是能单 agent 解决就不要拆，实在装不下了再考虑协作。

什么时候需要拆？拆的依据是"上下文隔离"和"权限隔离"。上下文隔离的意思是，你不希望客服 agent 在回答退货政策时还带着库存预测 agent 的一堆中间计算——这些信息只会干扰判断；权限隔离的意思是，不同 agent 能触碰的工具敏感度不同，拆开可以把高风险操作限制在特定 agent 内部。

协作模式上，最常用的是这三种：supervisor 模式（一个主 agent 负责任务拆分和结果汇总，其余 agent 做执行者）、流水线模式（每个 agent 处理一个阶段，输出传递给下一个）、peer 模式（agent 之间互相协商，动态编排）。我目前项目里主力用的是 supervisor 模式，因为它最可控——主 agent 相当于项目经理，它决定把活派给谁，能避免多个 agent 争抢同一个工具造成的冲突。

折一个具体的例子。我的数据运维工具拆成三类 agent：意图识别 agent（判断用户想干什么，需要哪些数据源）、数据操作 agent（负责查库、清洗、聚合，持有只读权限）、变更执行 agent（负责执行已审批的变更，持有写权限）。用户请求先进意图识别 agent，它输出一个"执行计划"，再由数据操作 agent 去获取数据，最后由变更执行 agent 在用户二次确认后落地变更。这样每个 agent 的上下文都很纯粹，权限边界也很清楚。

拆的粒度要小心。拆太细，agent 之间的通信开销和上下文搬运成本会吞噬收益；拆太粗，某个 agent 的提示词又膨胀到记不住自己的任务。一个判断标准：如果某个 agent 的 system prompt 超过 2000 字，就该考虑它是不是承担了太多职责。

4. 避坑指南：我踩过的和常见的问题

4.1 无限循环与重试风暴

agent-native 应用最常见的故障就是"模型卡在一个循环里出不来"。现象是：agent 反复调用同一个工具，返回同样的结果，然后再次调用，像录音机卡带一样。代码层面的最大步数限制能兜底，但会直接导致任务失败，不是真正的解决方案。

这个问题的根源是模型没有获取到足够的新信息来调整计划。我在一个库存查询场景里遇到过：模型反复调用"查询当日订单"工具，每次返回都因为订单数据还未同步而为空，模型就一直重试，完全不去想"是不是应该先查一下同步状态"。解决思路有两个。一个是给工具调用加上"已重试"的元信息——比如在上下文里追加一条系统消息"你已经重试了 3 次相同查询，结果均为空，请尝试其他工具或与用户确认"。另一个是在工具返回结果中主动携带诊断信息，比如"当日订单同步延迟，历史存量 1000 条可用"，给模型提供改变策略的线索。

另外，多工具场景还会出现"工具互踢皮球"的问题。agent 调用工具 A 失败，转去调用工具 B，B 又需要 A 的结果，于是又调 A。这种循环比单工具循环更难发现。我的对策是维护一个"已尝试动作清单"，每轮循环前把清单注入上下文，让模型看到哪些路径走不通。加上最大步数限制和 token 预算限制，双保险。

4.2 上下文爆炸与记忆管理

上下文爆炸是 agent-native 应用的慢性病。任务跑得越长，中间的临时内容越多，到最后上下文里全是各种工具结果、中间推理、错误信息，真正的用户需求反而被淹没。模型面对这种又长又脏的上下文，推理质量会显著下降。

我的解决方案是"两层记忆架构"。第一层是短期的会话记忆，放在上下文里，只保留最近几轮的关键信息；第二层是长期的工作记忆，放在外部存储里（我用的就是个简单的 JSONL 文件），保存任务背景、关键结论、待办事项。每轮推理前，程序从长期记忆里加载摘要，拼接到上下文开头，而不是把历史消息全量传入。

压缩频率也有讲究。压缩太频繁会丢失细节，影响推理质量；压缩太晚又会让上下文膨胀到不可用。我目前的做法是设一个 token 阈值，达到阈值后再触发压缩。压缩时用一个专门的小模型把历史对话总结成结构化摘要，包含四个字段：已完成动作、当前状态、遗留问题、下一步建议。实测下来，一个好的摘要能让 agent 在长任务中的表现不输给短任务。

还有一个容易被忽略的点：别把大段文档塞进上下文让模型"参考"。如果业务规则、字段说明这类静态知识比较多，应该走检索，让 agent 在需要时去查文档片段，而不是一开始就全部塞进去。静态知识用检索，动态状态放上下文，这个边界画清楚了，上下文膨胀问题能解决一半。

4.3 可观测性：agent 也要留痕

传统应用的日志记录一次请求的入参出参就够了，agent-native 应用完全不同。你要记录的不是一次调用，而是整个决策轨迹：模型每轮推理的输入是什么，它选择了哪个工具，参数是什么，工具返回了什么，模型又如何根据结果调整了计划。没有这些轨迹记录，出了问题你根本没法复盘，只能看着一个失败的结果干瞪眼。

我现在的做法是在主循环里埋点，把每一步的关键信息追加到一个 JSONL 日志文件：

{ "session_id": "8f3a2b…", "step": 1, "user_intent": "查询北京天气", "model_response": {"role": "assistant", "tool_calls": [{"name": "get_city_weather", "arguments": {"city": "北京"}}]}, "tool_result": "晴，18°C，风力3级", "latency_ms": 832, "tokens_used": 324, "decision": "continue" }

有这份日志，排查问题时我基本上能还原事故发生现场的每一步。有一次 agent 答非所问，我翻开日志发现它在第三步把用户提供的城市名拼错了，导致查询返回空，它就基于空结果编了一套天气。有了轨迹记录，这类问题五秒钟就能定位。

除了轨迹日志，我还给每个工具调用加了延迟和 token 消耗的统计。agent-native 应用的成本大头不是开发，而是推理。没有用量统计，账单来了你都不知道哪个 agent、哪个工具在烧钱。我们的经验是每周例行看一次 token 分布表，重点排查那些"高频调用但低频成功"的工具——通常这类工具需要优化提示词，或者调整参数约束。

4.4 评测困难：怎么判断它干得好不好

这可能是 agent-native 落地最大的痛点。传统软件有明确的对错，单元测试一跑就知道过没过；agent 的输出天然有随机性，同一请求跑三次可能给出三个版本的答案，其中两个正确一个有偏差。拿什么当评测标准？

我目前用的是三层评测体系。第一层是单步工具调用的正确性——在测试集里固定用户请求，看 agent 每一步选择的工具和参数是否符合预期，这一步可以用规则或者一个小模型来自动判定；第二层是最终结果质量——针对每个任务预设"必须包含的要点"，agent 的回答覆盖了多少要点，是否有幻觉信息；第三层是轨迹合理性——不只看结果，还要看 agent 的路径是不是合理的，是否存在来回折腾的无谓步骤。前两层可以自动化，第三层目前还是要靠人工评估。

评测集的设计也有讲究。要用真实的历史请求做样本，不能自己凭空想。我经常提醒团队的同事：你设计评测集时觉得"模型肯定能处理"的请求，恰恰是实际中不会出现的理想场景；实际用户问出来的话总是很糙、很口语化、夹杂各种背景信息。真实样本的评测才是有效的评测。评测频率上，我建议每次改完 prompt 或工具定义之后都要跑一遍回归测试集，不然你不知道改动是提升了还是倒退了。

5. 从业者经验与扩展思路

5.1 什么时候不该用 agent-native

聊了这么多 agent-native 的好处，也得泼盆冷水。不是所有系统都适合切换成 agent-native 架构，强行套用只会事倍功半。

固定流程的业务系统不适合。比如一个审批流系统，流程是国家规范或公司制度定死的，每一步是谁审批、什么条件下驳回，都是明确规则。这种场景用传统代码实现又稳又快，换成 agent 去"理解"流程反而引入不确定性。第二个不适合的场景是延迟敏感和强一致性要求的系统，比如交易系统，agent 推理要几百毫秒到几秒，还不保证结果一致，这在核心交易链路里是不能接受的。第三个场景是成本敏感的高频调用，如果每个请求都要跑一轮 agent 循环，token 开销会非常可观，而传统代码一次函数调用只是几毫秒的 CPU 成本。

我自己的选择框架很简单：这个任务是否存在开放性的、需要临场判断的决策空间？如果有，值得用 agent；如果是固定的确定性映射，别用 agent。拿招聘系统举例，"简历筛选是否符合硬性条件"是固定规则的查表，用代码；"综合评估候选人的主动性、沟通能力和发展潜力"是开放判断，适合 agent。

5.2 架构迁移的渐进路径

如果你决定在一个存量系统里引入 agent-native，我的建议是别搞大爆炸式重写，风险太高。用渐进式路径更稳妥：第一步，把一个低风险、独立性强的子流程改成 agent 驱动，比如工单分类、内容审核辅助；第二步，用 MCP 把周边工具能力标准化，让 agent 可以调用更多服务；第三步，验证效果和成本模型没问题后，再往核心流程推进。

每一步都要有明确的验证标准和回退方案。agent 方案效果不好就退回原来的代码路径，这不是丢人的事。我见过太多团队因为项目发起人面子问题，明明 agent 效果不行还硬撑着上线，最后用户全被坑了。技术选型没有高下之分，适合你的场景就是最好的。

从个人成长角度看，我越来越觉得做 agent-native 应用真正考验的不是模型知识，而是系统设计的思维转变。你要从"如何写一个正确的程序"转变到"如何设计一个容错的决策环境"，这中间包括能力边界的定义、上下文的管理、错误的恢复、评测的闭环。这些能力在传统软件工程里也有，但观察对象从代码变成了模型行为，调试思路完全不同。

5.3 我自己一直在用的三个小习惯

最后分享三个我踩过坑之后养成的小习惯，算不上什么高深理论，但很实用。

第一个习惯是给 agent 写"负面提示"。很多人写 system prompt 只写"你要做什么"，不写"你不要做什么"。我现在的 prompt 里一定会有一段负面清单，比如"不要编造不存在的工具结果"、"不要在数据不足时强行给出结论"、"不要重复调用相同参数的相同工具"。实测下来，负面提示对降低无效循环有奇效。

第二个习惯是在工具定义里写"何时不用"。每个工具的描述除了说明它能干什么，我还会补一句什么时候不该用它。比如天气工具的描述会写"无法提供历史气象统计，此类需求请使用数据分析工具"。这一招能显著减少模型选错工具的概率，比你在 prompt 里强调一万遍"请谨慎选择工具"管用得多。

第三个习惯是给关键的 agent 决策加"人工确认闸门"。具体做法是把需要确认的操作封装成一个特殊的"MCP 确认工具"——agent 认为需要执行高风险操作时，不是直接调用执行工具，而是先调用确认工具等待用户批准。这个设计让用户在关键时刻保有一票否决权，避免 agent 自作主张。在数据运维工具上线后的前三个月，这个闸门至少拦下了三次可能导致线上数据异常的误操作。

这三个习惯都不复杂，但对生产环境的稳定性提升非常明显。做 agent-native 应用，模型的推理能力决定了系统效率的上限，而这些工程习惯决定了系统的下限。把下限兜住了，再谈上限才有意义。