从零搭建大模型Agent系统：核心机制、工具调用与工程落地全解析-北京尧图网络

“Agent”这个词在圈子里喊了好几年但真正把它当成一个可以批量落地、能出活的技术方向来对待我觉得就是从“大模型应用”被拆成“模型能力”“工具调用”“记忆管理”“多步规划”这几个具体议题开始的。2026年被不少人说成Agent元年并不是模型又刷了什么榜单而是开发范式变了从“写提示词拿结果”变成“搭一套能让模型自己决策、自己纠错、自己调用工具的系统”。这篇内容我想从最贴近实战的角度把Agent到底是什么、适合解决什么问题、怎么从零开始设计一个可用系统、以及那些文档里不会写的坑完整梳理一遍。无论你是刚接触大模型的应用开发者还是已经在做RAG、写Workflow想往Agent方向进阶的人都可以直接拿这份思路去对照自己的项目。1. Agent到底是个什么东西从“对话机器”到“目标执行体”1.1 先厘清Agent、Chatbot、Workflow、RAG的关系很多人把Agent挂在嘴边但真到设计系统时才发现在术语上就已经打架了。我的理解里这四个东西的关系是递进的Chatbot只能一轮轮对话模型回答完就结束了没有状态、没有行动。Workflow把流程写死比如先检索再总结再回复每一步都是预设的模型只是流程里的一个组件。RAG在回答前先从外部知识库捞资料本质上增强模型的“记忆”但依然是被动的。Agent把“目标”交给模型模型自己决定下一步做什么可能需要调用检索、调用计算器、写代码执行、查数据库做完一步再决定下一步直到完成目标。用一个生活化的类比Workflow像自动售货机你投币、按键、它出货流程永远是那几步Agent像你雇了一个实习生你跟他说“帮我把这份报告整理好”他会自己决定先查资料、再列提纲、写到一半发现数据不够又去补充查询最后交付一个完整结果。这个“自己决定下一步”的能力就是Agent和前面三类东西最本质的差别。1.2 Agent系统的四个核心模块一套完整的Agent系统我习惯拆成四个模块来看缺一个都会觉得“差点意思”规划模块Planner把大目标拆成小步骤并决定当前该执行哪一步。这里是大模型发挥“推理”能力的主场可以采用ReActReason Act模式让模型每轮思考“现在我该做什么、怎么做”。工具模块Tools模型可以调用的外部能力比如搜索引擎、数据库查询接口、计算器、代码解释器、HTTP请求。工具的本质是把模型的“想法”变成“动作”。记忆模块Memory保存对话历史、任务进度、用户偏好。短期记忆管当前任务上下文长期记忆管跨会话的信息。执行与反馈模块Execution Feedback执行工具调用把结果反馈给模型让模型判断是否继续、是否换一种方式。理解这四个模块你再看市面上的Agent框架会发现它们都在帮你解决这四件事的编排问题。别被层出不穷的名词绕晕架构上就是这四板斧。1.3 Agent适合解决什么问题不是所有任务都该做成Agent。我自己的判断标准是任务必须满足“目标明确、路径不固定、环境可反馈”三个条件。目标明确用户说“帮我订一张周五去上海的票”目标是清楚的。路径不固定到底用哪个App订、选哪个航班、要不要中转这些步骤没法预先写死。环境可反馈每一步都能拿到结果比如余票信息、价格变化模型会根据反馈调整下一步。反过来如果任务路径非常固定比如“每天定时把某个接口的数据写入数据库并发送告警”那用Workflow就好稳定、可控、省成本。把简单任务强行Agent化只会引入更多不确定性和调用成本。2. 大模型应用的技术底座选型模型、框架与工具链2.1 模型能力的分层选择做Agent系统模型选型是最基础也最容易被低估的一环。2026年的市场环境下我的建议是分三层来看轻量级任务意图识别、实体抽取、简单分类选择小参数模型即可速度快、成本低。中等级别任务多轮对话、工具调用、短流程规划适合用通用能力较强的中等规模模型。复杂任务多步骤规划、长上下文理解、错误恢复需要旗舰级模型这类模型通常具备更强的工具调用遵循能力和长程推理一致性。选模型的关键指标不是排行榜分数而是三件事工具调用遵循率能不能按格式输出正确的调用参数、长上下文稳定性聊到后面会不会忘前面、推理成本跑一次复杂任务的token消耗。我见过不少项目一开始奔着最强模型去结果成本翻了十倍效果提升却不到百分之五。先想清楚自己的任务复杂度再决定用哪一档模型。2.2 框架选型的现实考量Agent框架这几年的演进速度很快几乎每个月都有新东西出来。我的建议是不要盲目追新按这几个维度评估生态成熟度社区活跃吗示例多吗遇到问题搜得到答案吗可调试性能不能方便地查看每一轮规划、每一次工具调用、每一步的输入输出可扩展性接自定义工具方便吗记忆模块能替换吗能不能在不重写核心代码的情况下加功能部署友好度本地部署、云部署、容器化的支持是否顺利我自己在项目里常用的套路是先用成熟框架快速搭原型验证核心流程跑得通再根据实际需要逐步把部分模块替换成自研实现。框架是脚手架不是牢笼不要为了用框架而用框架。2.3 工具链与数据流设计Agent系统的工具链决定了模型“手有多长”。工具设计有几个原则单一职责每个工具做一件事接口尽量简单。比如“获取天气”和“获取空气质量”分开别合成一个带参数开关的工具。描述清晰工具的描述信息对模型非常重要模型是靠描述来判断什么时候该调用这个工具的。描述里写清楚“什么时候用”“参数是什么”“返回什么”。失败容错工具会超时、会报错模型需要能理解错误信息并尝试替代方案。最好在工具返回结构里预留错误字段。数据流上要注意“工具返回的信息不一定干净”。比如搜索工具返回的网页摘要可能夹杂广告文本要提前做清洗数据库查询结果的字段命名可能对模型不友好要做一层映射。这层脏活累活没做好Agent的稳定性会直线下降。3. Agent核心机制深度解析规划、记忆与工具调用3.1 规划模式的三种主流设计规划是Agent的大脑目前主流的模式有三种ReActReason Act模型交替输出“思考”和“行动”思考决定下一步行动调用工具工具结果回到模型继续思考。实现简单适合大多数场景。Plan-and-Execute先让模型生成一个完整的执行计划再逐步执行。适合任务步骤相对明确、需要先给用户展示计划的场景但灵活性不如ReAct如果计划出错后续调整成本较高。Tree-of-Thoughts每一步尝试多条路径保留多个候选方案最后选择最优解。效果上限高但成本也高适合复杂推理类任务不太适合普通业务场景。我的经验是80%的场景用ReAct就够了别一上来就上复杂机制。先把最简单的跑通再根据卡点去升级。很多项目的瓶颈其实不在规划算法而在工具返回质量、上下文管理这些外围环节。3.2 记忆模块的分层设计记忆是Agent“越用越懂你”的关键设计上分三层短期记忆当前会话内的对话历史和任务进度通常直接放在上下文里注意控制长度超长要裁剪或摘要。长期记忆跨会话的用户偏好、历史事实通常存向量数据库需要时检索出相关片段注入上下文。工作记忆当前任务的中间状态比如“已经查了广州的天气接下来要查深圳的”这种状态如果丢了Agent会重复劳动甚至跑偏。记忆模块做得好的Agent和做得差的Agent体验差距非常大。差的Agent每次对话都像失忆用户要反复重复需求好的Agent会记住用户偏好的表达风格、上一次没聊完的话题、这个项目里反复使用的技术栈。记忆本质上是“用存储换上下文”把不必要塞进窗口的信息放到外部需要时再捞回来。3.3 工具调用协议与参数约束工具调用是最容易出bug的环节。模型输出要调用某个工具但参数就是不对常见的坑有三类参数名不匹配工具定义里叫“user_id”模型输出“userId”导致解析失败。解决方式是给工具参数起名时就用模型容易理解的命名并且在描述里写清楚。参数值格式错误日期格式、JSON结构、枚举值匹配不上。要在工具层做严格的入参校验错误信息要能反馈给模型让它自己修正。多工具选择混乱多个工具功能相似模型选错。尽量精简工具数量功能重叠的要合并或者在描述里写明“如果没有XX需求不要调用本工具”。我强烈建议每个工具都做两层校验第一层是格式校验由代码完成第二层是语义校验由模型在调用前通过描述理解。两层都过了才真正执行。4. 手把手搭建一个带检索和工具调用的Agent系统4.1 环境准备与最小工程结构说再多理论不如直接上手搭一个最小可用的Agent。我这里的示例是一个“本地文件检索天气查询”的Agent用户可以问“帮我看看项目文档里有没有关于部署的说明顺便看看北京今天适不适合户外部署”。先准备环境假设你已经有Python 3.10和基础的大模型API调用能力pip install openai langchain chromadb requests工程结构建议保持简单agent_demo/ ├── main.py # 主入口编排逻辑 ├── tools.py # 工具定义 ├── memory.py # 记忆管理 └── config.py # 模型配置与常量这个结构对于学习期完全够用后续要加功能再横向扩展。不要一上来就套一堆插件和中间件调试成本会淹没你的学习主线。4.2 模型配置与工具定义实现先写config.py把模型配置集中管理# config.py MODEL_NAME your-model-name # 替换成你的模型 API_BASE your-api-endpoint API_KEY your-api-key SYSTEM_PROMPT 你是一个智能助手能够通过检索本地文档和查询外部信息来回答用户问题。在回答之前请先判断是否需要调用工具。如果需要调用工具请严格按照要求的格式输出。如果工具结果不足以回答问题请明确告知用户。然后在tools.py里定义两个工具。第一个是本地文档检索基于向量数据库# tools.py import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection( namedocs, embedding_functionembedding_functions.DefaultEmbeddingFunction() ) def retrieve_docs(query: str, top_k: int 3) - list: 检索本地文档库返回最相关的内容片段。适用场景用户问题涉及项目文档、知识库内容时使用。参数 - query: 用户的检索问题字符串类型。 - top_k: 返回数量默认3。返回包含文档片段和来源的列表。 results collection.query(query_texts[query], n_resultstop_k) return results[documents]第二个工具是天气查询模拟一个外部API调用# tools.py import requests def get_weather(city: str) - dict: 查询指定城市的实时天气信息。适用场景用户询问天气、温度、是否适合户外活动时使用。参数 - city: 城市名称字符串类型例如北京。返回包含温度、天气状况、风力等信息的字典。 # 这里是模拟接口实际项目替换为真实天气API url fhttps://api.example.com/weather?city{city} resp requests.get(url, timeout10) resp.raise_for_status() data resp.json() return { city: data[city], temperature: data[temp], condition: data[weather], wind: data[wind] }注意工具函数的docstring千万别偷懒模型就是靠这个描述来判断调用时机的。我曾经见过一个工具描述写得太模糊模型在不需要调用的时候也去调白白浪费时间和token。4.3 记忆管理与主循环编排memory.py里我做一个非常简单的列表式记忆管理实际项目可以用数据库或向量库替换# memory.py class SimpleMemory: def __init__(self, max_turns10): self.history [] self.max_turns max_turns def add_user_message(self, content): self.history.append({role: user, content: content}) self._trim() def add_assistant_message(self, content): self.history.append({role: assistant, content: content}) self._trim() def add_tool_result(self, content): self.history.append({role: system, content: f工具结果: {content}}) self._trim() def get_messages(self): return [ {role: system, content: SYSTEM_PROMPT}, *self.history ] def _trim(self): if len(self.history) self.max_turns * 2: # 简单裁剪只保留最近的内容 # 实际项目这里应该做摘要压缩 self.history self.history[-self.max_turns * 2:]核心循环在main.py里逻辑就是经典的ReAct模式模型输出如果是工具调用请求就执行工具把结果放回上下文让模型继续如果是最终回答就返回给用户。# main.py import json from config import MODEL_NAME, API_BASE, API_KEY, SYSTEM_PROMPT from tools import retrieve_docs, get_weather from memory import SimpleMemory # 这里用你实际使用的SDK下面是伪代码示意 def call_llm(messages): # 调用大模型返回文本 pass TOOL_MAP { retrieve_docs: retrieve_docs, get_weather: get_weather, } def parse_tool_call(text): 解析模型输出的工具调用指令返回工具名和参数。 try: data json.loads(text) if tool in data and params in data: return data[tool], data[params] except json.JSONDecodeError: pass return None, None def run_agent(user_input, memory): memory.add_user_message(user_input) for step in range(10): # 防止无限循环设置最大步数 messages memory.get_messages() response call_llm(messages) tool_name, params parse_tool_call(response) if tool_name and tool_name in TOOL_MAP: # 执行工具 try: result TOOL_MAP[tool_name](**params) memory.add_tool_result(result) except Exception as e: memory.add_tool_result(f工具执行出错: {e}) continue else: # 模型认为是最终回答 memory.add_assistant_message(response) return response return 任务步骤过多已自动停止请尝试简化问题。 if __name__ __main__: user_input 帮我检索项目文档里关于部署的说明并查询一下北京今天的天气是否适合户外作业 result run_agent(user_input, SimpleMemory()) print(result)上面这段是教学用的精简版真实项目中你大概率会直接用框架封装好的AgentExecutor但理解这个最小循环非常重要因为所有复杂的机制都是从这十行核心逻辑生长出来的。4.4 让模型稳定输出工具调用指令在上面的例子里parse_tool_call依赖模型输出JSON格式的指令。实测中让模型稳定输出JSON是一件需要专门调教的事。我的经验是做好三件事在系统提示词里写清楚工具调用的输出格式最好给出正反两个示例。设置温度参数调低一点比如0.1减少格式漂移。在代码里做好容错解析支持多种格式变体比如有的模型会输出markdown代码块包裹的JSON要去掉外壳再解析。另外不要把工具调用输出和最终回答混在一起。可以约定模型要么输出工具调用指令包含“tool”和“params”字段要么输出纯文本回答不要两者一起。混着输出会让解析逻辑变得非常痛苦。5. 生产化落地工程化改造与稳定性保障5.1 从Demo到生产的必要步骤Demo跑通只是第一步真正上生产还有很多活要干。我整理一个生产化清单模型交互日志每一步的模型输入输出、工具调用、耗时、消耗token全部记录。这是排查问题的基础。超时与重试机制模型调用会超时、工具会超时要设置合理的超时时间和重试策略。并发控制Agent任务往往比普通对话耗时更长要预估并发上限做好限流。安全与权限工具能执行什么操作、能访问什么数据必须做严格鉴权。尤其是有写操作、支付操作的工具一定要二次确认。可观测性链路追踪、指标监控、告警。不指望第一天就完善但日志一定要先有。5.2 上下文窗口管理策略上下文窗口是Agent系统最贵的资源管不好就是烧钱机器。几种常用策略裁剪丢掉最早的历史消息简单粗暴适合短期任务。摘要定期把历史对话总结成摘要塞回上下文。适合长会话。检索增强把重要信息存向量库需要时检索回来。适合知识密集型任务。结构化压缩把工具调用结果压缩成表格、关键字段列表比塞原文省得多。我见过一个项目工具返回一个5000字的API文档模型每次都要把这5000字重新读一遍去回答一个简单问题。后来改成提前对文档做结构化解析只把相关的字段传给模型成本和响应速度都大幅改善。省token就是省成本别忽视这个优化点。5.3 成本控制与性能调优Agent的调用成本比普通对话高出不少因为每一轮工具调用都意味着一次模型推理。成本控制的几个思路减少不必要的工具调用在提示词里明确“只有当你确定需要外部信息时才调用工具”。缓存复用同样的用户问题、同样的检索结果可以做缓存避免重复计算。模型分级简单的判断用小模型复杂的规划用大模型做一个路由层。批量处理如果任务不要求实时响应可以用异步批量处理来摊薄成本。性能调优上最影响体验的是“首响应时间”。用户发出指令后如果Agent要思考好几秒才动体验会很差。可以考虑先返回一个“正在处理”的占位响应再异步执行Agent任务完成后通知用户。这样能给后端更多处理时间用户也不会觉得系统卡死。6. 上手避坑与踩坑记录那些文档不会告诉你的细节6.1 规划失控Agent陷入死循环新手做Agent最常遇到的问题是模型反复调用同一个工具或者不断输出一样的思考陷入死循环。我的排查思路是先看日志确认模型在每一轮的输入输出是什么是不是上下文里已经包含了足够的信息但模型还是傻傻地调用工具。限制最大步数代码里一定要有步数上限这是我的血泪教训。没有上限的Agent一旦失控会持续消耗你的token直到余额报警。改进提示词明确告诉模型“如果你已经获取了足够信息请直接回答不要再调用工具”。检查工具结果有时候工具返回的内容很差模型读不到有效信息只能不断重试。这时候要优化工具返回的内容而不是怪模型。6.2 工具返回信息解析失败工具返回了数据但模型一头雾水这种情况多半是返回结构的问题。比如天气API返回的字段叫“hum”模型不知道这是湿度数据库返回的时间戳是一串数字模型不知道怎么格式化。解决办法是在工具层做好数据清洗把字段名改成人类可读的并且统一格式。我一般会在工具返回前做一次“面向模型的格式化”把返回内容整理成一句话描述或简洁的键值对。6.3 记忆污染与上下文混乱当工具返回结果被塞进上下文后模型容易把工具结果和对话内容混淆甚至把检索出来的文档内容当成自己“知道”的回答得过于自信。怎么避免我的经验是给工具结果加明确的前缀标明“这是工具检索结果不是你的知识”。在系统提示词里强调“当使用检索内容回答时请说明信息来源”。定期清理历史消息工具结果在完成任务后及时压缩。记忆污染是Agent开发里最隐蔽的问题表面看回答很流畅实则模型在胡编。要通过日志和人工抽检来持续监控。6.4 微观技巧与调参心得最后分享几个调参的微观技巧都是我实测下来有效的温度参数工具调用场景温度调低0~0.3创意写作场景温度调高0.7~1.0。同一个Agent内部不同环节可以设置不同温度。系统提示词不要写得像法律条文要像操作手册。模型更擅长遵循“遇到情况A做B”这种条件式指令。工具数量控制在5~10个以内。工具太多模型选择困难调用准确率会明显下降。每次修改提示词后准备一组固定的测试用例来回归验证。很多项目改一个词的提示词导致其他场景崩掉没有测试集根本发现不了。强烈建议记录每一轮Agent的详细日志只要能回放大部分问题都能定位。7. 成本、安全与合规视角下的Agent落地考量7.1 成本模型不只是token费用Agent的成本结构比传统API调用复杂得多。除了模型推理费用还有工具调用的基础设施成本数据库查询、第三方API调用、代码执行环境等。开发调试成本Agent的调试比普通代码调试难得多因为涉及大量模型输出不确定性。维护成本模型升级可能导致之前调好的流程变化需要持续跟踪。我的建议是上线前先做一个成本预估按每次任务的平均调用轮数、每轮的平均token数乘上预估的日活算出一个大致的日成本。这个数字会让你重新审视每一步优化是否值得。7.2 安全与隐私边界Agent能调用的工具越多安全风险就越高。几个必须守住的红线只允许Agent调用最小权限的工具不要给它一个能删库的接口。涉及用户隐私信息的处理要有明确的授权流程。对外部工具返回的内容要做过滤防止注入攻击。所有Agent的动作尤其是对生产系统有影响的操作必须可审计、可回滚。安全设计不能等上线后补要从第一行代码开始就考虑。我见过有团队为了让Agent演示效果炫酷给它接了一个能直接改数据库的工具结果演示时模型误操作删了一行测试数据虽然没造成大事故但把团队吓得不轻。7.3 评估体系建设怎么量化Agent好不好Agent系统怎么评估是一个常被忽略的问题。我建议从三个维度建立评估体系任务完成率用户的目标在几步之内被完成完成质量如何这是最核心的指标。过程健康度平均调用轮数、工具调用失败率、无效调用比例。用户体验响应速度、回答准确性、用户后续提问是否减少说明一次就到位。评估的关键是要有一组标准的评测用例覆盖正常场景、边缘场景、异常场景。每次改模型、改提示词、改工具都跑一遍这组用例用数字对比效果而不是凭感觉说“好像变好了”。8. 从“用”到“造”进阶路径与扩展方向8.1 多Agent协作的设计思路做完单个Agent之后下一个自然的方向是多Agent协作。常见模式有三种主从模式一个主Agent负责任务分解多个子Agent各负责一个子任务。同侪模式多个Agent平级协作每个Agent负责一个专业领域通过消息传递协作。竞争模式多个Agent分别产出方案由一个评审Agent或用户来选优。多Agent不是越多越好每增加一个Agent系统的复杂度和成本都成倍上升。我的建议是从两个Agent开始练手比如一个负责信息收集、一个负责最终输出跑通了再增加角色。8.2 Agent与其他技术栈的结合Agent不应该是孤立的存在它可以和很多技术栈结合起来产生更大的价值Agent RAGAgent负责判断什么时候该检索RAG负责高效检索天然互补。Agent 定时任务把Agent包装成周期性执行的服务比如每天早上自动汇总邮件、生成简报。Agent 代码生成让Agent直接写代码、跑测试、根据报错修代码这是目前工具链里效果非常显著的方向。Agent 可视化大屏把Agent的决策过程、工具调用链实时可视化便于演示和调试。一个比较好的思路是先找一个你自己工作里重复性最强、但又需要一点判断力的任务把它Agent化试试。比如每天整理多个来源的信息生成日报这种任务路径不固定但目标明确特别适合Agent。8.3 学习路线建议从哪里开始最有效如果你刚接触Agent我推荐这条学习路线先理解大模型的基本原理和API使用把一个普通对话跑通。自己实现一个最小ReAct循环不做任何框架体会Agent的核心逻辑。引入第一个工具比如搜索或计算感受工具调用对能力的扩展。用一个现成的Agent框架把之前手写的能力迁移过去体会框架的抽象价值。开始做记忆管理、上下文压缩、工具链扩展这些进阶功能。最后再考虑多Agent、评估体系、高可用部署这些生产级问题。不要跳过第2步手写最小循环是理解Agent本质最好的方式。框架会帮你加速但也可能让你失去对底层机制的感知。我见过不少开发者用了半年框架最后还是说不太清楚ReAct循环里到底发生了什么这种状态并不利于排障和优化。我还想特别说一句Agent开发的核心能力其实不只是“调模型”而是系统设计能力。你得懂得任务拆解、懂得状态管理、懂得怎么让一个充满不确定性的系统在可控范围内运行。这些能力在传统软件开发里就有只是在Agent语境下它们以新的形式出现了。多写代码、多跑实验、多记录失败案例比任何教程都管用。我个人在实际操作中的体会是做Agent项目技术选型其实只能占据两成的重要性剩下八成都在跟“不确定性”做斗争。模型会输出奇怪的格式、工具会返回预料之外的错误、明明上次还能跑的流程换个模型版本就崩了。真正能让一个Agent项目成功的不是某个酷炫的框架而是一套扎实的日志体系、一组覆盖全面的评测用例、以及一次次耐着性子把失败案例吃透的积累。如果你正准备开始自己的第一个Agent项目我的建议是先别追求面面俱到找一个足够具体的任务把它做到每周稳定运行不倒再考虑扩展。把最小的闭环打磨扎实比做一个华丽但跑不稳的演示系统有价值得多。

从零搭建大模型Agent系统：核心机制、工具调用与工程落地全解析

相关推荐

YOLOv11对抗攻击与防御实战：从FGSM到鲁棒性提升

PB客户端远程连接SQL Server完整方案：动态IP与DDNS自动重连实战

RAG技术2025复盘与2026展望：混合检索、重排序与工程落地

更多资讯

AI辅助毕业论文写作：从选题、文献综述到查重降重的全流程实战指南

LoRA微调法律大模型：数据形态与样本构造才是效果关键

基于YOLO的无人机目标检测系统：从数据到部署的工程实践

VS Code 插件开发：用 TreeView 打造可复用的资源管理器视图（TaoToken 统一 Key 接入）

FLUX 3 Image Klein背后的安全设计：NSFW分类器、内容溯源与负责任AI实践

深入理解 Claude Code 源码：终端 Agent 的工程解剖与实现

今日更新

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？