企业官网建设流程全解析

今天的日报，我照例把社区里关于Agent和LLM的讨论按主题过了一遍。和前几天相比，有几个方向的热度明显在上升——安全攻防开始从“提示词注入”往更深的记忆与知识库层面走，Agent Skills这类偏工程化的概念被越来越多的人拿来和Tool做区分，开发者在实际跑Agent项目时遇到的报错和评测问题也开始沉淀出一些可复用的经验。这篇文章就是我对这些内容的整理和解读，不是简单罗列链接，而是把我看到的值得关注的问题、背后逻辑和实操判断一起放进来，方便你快速定位哪些信息和你手头的事情相关。

1. Agent攻击面在扩大：从记忆投毒到自主容错控制

1.1 AgentPoison：污染记忆的红队攻击思路

“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”这个话题今天讨论度不低。它本质上是一类针对Agent记忆与知识库的红队研究：攻击者不再费劲写提示词注入，而是直接把恶意内容埋进Agent会检索的记忆片段或知识库里，让Agent在特定场景下被“带偏”。

这个思路之所以值得重视，是因为它和传统RAG（检索增强生成）的攻击路径有明显区别。普通RAG主要是用户输入侧的问题，攻击者想办法让检索出来的文档内容包含恶意指令；而AgentPoison这类工作关注的是Agent的长期记忆。Agent会把对话历史、任务执行结果、用户偏好这些信息写入向量数据库，下次任务时根据相似度做召回。攻击者如果在某次交互中成功诱使Agent把一段“看似无害但实际夹带恶意指令”的内容写入记忆，那么后续所有依赖这段记忆的任务都可能被污染，而且很难察觉——因为Agent检索到的内容是它“自己记住的”。

从防御角度看，我建议做Agent项目的团队至少先做三件事：

1. 记忆写入校验：不是所有对话内容都配写入长期记忆。要在写之前做来源标记、内容分类，并过滤掉包含可执行指令或系统级控制词的片段。
2. 权限隔离：记忆库按用户或会话隔离，至少不能让一个普通用户的输入影响另一个用户Agent的行为。
3. 定期审计：对记忆库做抽样检查，重点看有没有异常的指令性文本。

这类攻击目前还没有特别成熟的检测方案，先把写入口子收窄是最容易落地的。

1.2 识的LLM智能体自主容错控制：长链路任务的工程防线

今天热词里有一串“识的llm智能体自主容错控制:构建可靠ai系统的工程实践”，虽然表述有点绕，但指向的问题很实在：Agent在做多步任务时，错误是会累积的，而构建可靠系统恰恰需要容错机制。

Agent执行一个任务，通常要经历“理解意图—拆解步骤—调用工具—检查结果—决定下一步”这样的循环。任何一个环节出错，如果系统不做处理，错误会顺着链路一路传递下去。比如一个写代码的Agent，第一次调用工具时接口返回了超时，它可能误以为工具不存在，然后改变策略，甚至越走越偏。

我理解的自主容错控制，至少包含三个层次：

• 工具调用层：对单次工具调用的失败做分类。超时、参数不合法、权限不足、服务端报错，这些不同类型的失败，重试策略应该不一样。超时可以考虑等待后重试，参数不合法就应该停下来修改参数而不是傻重试。
• 任务执行层：维护一个执行计划快照，Agent每一步执行前后都能对比“计划中该做什么”和“实际发生了什么”。如果偏差超过阈值，触发重新规划，而不是硬着头皮往下走。
• 状态管理层：把Agent的中间状态（已执行步骤、已获取信息、可用余额等）显式记录下来，这样即使某次执行中途挂了，恢复后还能从断点继续，而不是从零开始。

实操中比较笨但有效的方法是：给Agent的每次工具调用包一层统一的日志包装器，记录输入、输出、耗时和错误类型。跑一段时间之后，你基本上能看出哪类任务在哪个环节最容易崩，容错策略也就有数据支撑了。

1.3 Agent安全不只是提示词注入，权限与落盘都要管

“agent安全”这个热词挂在榜上不算意外。现在做Agent的人多了，安全讨论也从最初盯着“提示词注入”这一件事，慢慢扩展到更宽的工程面。我自己看项目时比较关注的是下面这几个容易忽略的点：

外部工具权限过大。很多Agent框架默认给工具开放的权限是整个工作区的读写。真跑起来就发现，一个搜索工具根本不需要删除文件的权限。建议按最小权限原则给每个工具配独立的权限描述，至少在某一步出错时，不至于把整个环境带崩。

落盘数据的敏感度。Agent执行任务往往会临时保存中间结果，如果直接把用户对话内容或API返回内容原样写到本地文件，再被日志收集系统捞走，隐私风险就出来了。团队里最好约定一套敏感信息过滤规则，落盘前统一跑一遍。

第三方包的供应链风险。现在很多Agent项目直接引用了社区里的框架和插件，这些包本身的更新频率和维护情况参差不齐。引入之前至少看一下它的依赖树和最近的commit记录，这个习惯能省掉很多潜在的坑。

说到底，Agent安全目前还没有一套“一招鲜”的解决方案，但把权限、数据、依赖这三个基础面管好，已经能挡住大多数常见的低级问题。

2. 框架与架构层：harness和agent到底差在哪

2.1 社区追问最多的“Agent框架与编排”是什么

“agent框架”和“agent框架与编排”连续出现在热词里，说明这两天的社区讨论里，概念澄清类内容需求很旺盛。我猜原因是Agent项目多起来之后，大家发现用现成框架写好一个Demo不难，难的是搞清楚框架到底帮你解决了什么问题、哪些问题还得自己动手。

市面上常见的Agent框架大致可以分三类：

• 专注于Agent循环的：比如让模型循环“思考—调用工具—观察结果”，这类框架把执行循环封装好，你只要注册工具、定义指令。
• 专注于编排的：强调多个Agent之间的协作、消息传递和任务分配，适合复杂工作流。
• 专注于记忆与知识管理的：帮你管理向量库、对话历史、长期记忆的读写。

选型的时候，我最常给出的建议是：先想清楚你的核心需求到底是“让一个Agent稳定地干完一件事”，还是“让一堆Agent分工干一系列事”。前者用简单框架甚至自己写循环就够了，后者才需要认真研究编排方案。框架本身不是越重越好。

2.2 Harness是容器，Agent是决策者

“harness和agent区别”这个热词说明很多人被这两个词绕晕过。我第一次接触时也困惑了一阵，后来我自己用一个类比把它讲清楚了：harness是生产线，agent是生产线上的操作员。

具体来说，harness负责Agent运行时的所有“后勤”工作：

• 管理模型接口，包括请求的发送、重试、流式响应；
• 维护上下文窗口，决定哪些历史信息要保留、哪些该被压缩；
• 加载和注册工具列表，检查工具传入的参数格式；
• 执行安全策略，比如拦截高风险的调用；
• 记录日志，保存执行轨迹。

而Agent本身是决策逻辑：它根据当前目标和收到的观察结果，决定下一步调用哪个工具、给工具传什么参数、要不要结束任务。

把这两个概念分开理解，对排查问题特别有帮助。比如你看到一个Agent报错“工具执行失败”，可能是Agent决策错了（选了不该选的工具），也可能是harness在传参或环境配置上出了问题。调试的时候先分清楚是决策层的问题还是执行层的问题，能省掉大把时间。

2.3 多Agent协作的编排问题，单Agent够用就别硬上

“多agent”这个话题也是高频热词。很多人问：是不是用多个Agent就显得更高级、效果更好？我的答案是：不一定。

多Agent协作的收益通常出现在任务本身可以清晰拆分的场景，比如“资料搜集Agent”和“文案撰写Agent”并行工作，之后再汇总。这种模式的好处是每个Agent的职责单一、上下文更干净、工具权限也可以隔离。

但多Agent也会带来几个新问题：

• 上下文共享：Agent之间怎么传递信息？是共享一个上下文，还是通过消息队列？传递什么、过滤什么，都需要设计。
• 任务冲突：两个Agent同时编辑同一个文件，谁来合并？还是直接锁掉？
• 故障扩散：一个Agent把错误结果传给另一个Agent，错误会被放大。所以多Agent之间的消息最好带上置信度或来源标记。

我的建议是：先做一个单Agent的完整流程跑通，再考虑拆成多Agent。如果单Agent已经能把任务稳定完成，那拆分支的收益可能并不大，反而引入了更多协调成本。

3. Agent Skills从尝鲜走向工程化：工具链和实操细节

3.1 Skill、Tool和Prompt的分工

“agent skill教程”“agent tool agent skills”这些热词放在一起看，说明社区正在把“Skill”当作一个独立概念来讨论。之前大家习惯把Agent的能力扩展统称为“工具”，现在越来越多的人开始区分“Tool”和“Skill”。

我理解的边界是这样的：

• Tool是Agent可以调用的具体函数或API，有明确的输入输出，比如“搜索网页”“读取文件”“执行代码”。Tool是原子能力。
• Skill是将一组Tool调用、决策规则和领域知识打包成的一套可复用的“工作流程”。Skill处理的是一个相对完整的任务目标，比如“把网页保存为Markdown”就是一个Skill，它可能需要调用“获取网页内容”“提取正文”“转换格式”“写入文件”等多个Tool。

Prompt则更偏“一次性”的指令文本，告诉模型在当前任务里怎么表现。Prompt和Skill最大的区别在于复用性：Skill一旦做好，可以在不同项目、不同场景里反复调用，而且可以迭代升级。

这个区分之所以重要，是因为它改变了Agent开发的思考方式。以前遇到一个新任务，第一反应是写一个详细的Prompt；现在会先想：这个任务的通用流程是什么？那些步骤可以沉淀成Skill？这样你的Agent能力库会越来越厚，而不是每次都在Prompt里堆临时的指示。

3.2 实操案例：写一个“网页保存成Markdown”的Skill

“agent 将网页保存成markdown的 skill”这个热词非常具体，我用它来做例子，把你把Skill开发的基本流程讲清楚。

一个完整的网页保存Skill通常包含以下部分：

Skill元信息

• 名称：webpage_to_markdown
• 描述：抓取指定网页内容并转换为干净的Markdown格式保存到本地
• 适用场景：收藏文章、整理资料、离线阅读

执行步骤

1. 校验输入的URL格式，支持http和https协议；
2. 获取网页内容，设置合理的Timeout，处理重定向；
3. 提取正文内容，过滤导航、广告、脚本等干扰元素；
4. 识别语言和编码，处理乱码问题；
5. 将正文转换为Markdown格式，保留标题层级、链接、图片地址；
6. 保存到指定目录，文件名根据文章标题自动生成；
7. 保存完成后返回文件路径和简要摘要给用户确认。

需要的Tool

• web_fetch（获取网页内容）
• text_extractor（正文提取）
• markdown_converter（HTML转Markdown）
• file_writer（写入文件）

注意事项

• 如果网页内容需要登录才能访问，Skill应该提前检测并提示用户，而不是直接返回“失败”；
• 有些网页是动态渲染的，直接抓取静态HTML可能只有空壳，这时候需要headless浏览器之类的工具；
• 转换完成后最好让Agent自查一遍：标题有没有丢失？正文是否完整？图片引用是否有效？

把上述内容结构化存好，就是一个可复用的Skill。下次你再让它整理其他网页，Agent就能按这套流程走，不需要你在Prompt里重新描述一遍。

3.3 第三方工作台与官方Skills生态：Hermes Agent和Claude Skills

今天热词里出现了不少和具体产品相关的词：“hermes agent”“hermes agent obsidian”“hermes agent安装”“claude agent skills: a first principles deep dive”。

Hermes Agent这类第三方工作台之所以吸引人，是因为它把Skills做成了可视化的管理界面，你可以在工作台里配置技能、绑定知识库、调整Agent的行为，而不需要直接写代码。尤其是配合Obsidian这类笔记工具使用，可以把个人知识库变成Agent的活资料库——写笔记、整理链接、生成摘要，这些操作被拆成一个个Skill挂在工作台里，随时取用。

与此同时，Claude Agent Skills掀起的那波“从第一性原理理解Skills”的讨论也还在继续。它的核心观点是：Skills设计应该回归“让模型在多步任务中稳定复现流程”的本质，不要把Skill当成简单的Prompt模板。真正有效的Skill，通常具备这几个特征：

• 步骤明确且可执行；
• 每个步骤都定义了输入、输出和成功标准；
• 包含异常分支的处理方法；
• 有元描述，让模型知道“什么情况下该用这个Skill”。

从使用者的角度看，我是这么选型的：如果只是个人使用，想快速搭建一个能处理笔记和日常事务的Agent，那Hermes Agent这类带图形界面的第三方工作台会更省心；如果是在做产品，需要深度定制Agent行为，那我建议自己定义Skill规范，用开源框架来控制整个流程，可维护性会更好。

4. 开发侧一天遇到的两个报错：工具载荷与执行终止

4.1 “provider rejected the request schema or tool payload”排查实录

“llm request failed: provider rejected the request schema or tool payload.”这条报错信息今天被好几次搜索，说明不少人在调Agent工具调用时碰到了同一个问题。报错信息直译是“模型服务商拒绝了请求，因为Schema或工具载荷不合法”。

这个问题的本质是：你在Agent配置里注册的工具参数定义，和模型返回的工具调用参数不匹配，被服务商在API层拦下来了。常见的原因有：

1. Tool参数定义了必填字段，但模型调用时没给全。比如你要求必须传“file_path”和“mode”，模型只传了前者。
2. 参数类型不匹配。比如你定义“fields”是数组类型，模型传了个字符串。
3. 额外参数混入。模型生成了你没在Schema里定义的参数名称。
4. Schema本身写得不规范。比如缺少“type”字段，或者对象属性没有“properties”声明。

我排查这类问题时的思路是：先用隔离法定位。把工具列表删到只剩一个最简单的工具，如果还报错，说明问题出在Schema定义本身；如果不报错，再逐个加回工具，直到复现为止。

另外一个技巧是：在发给模型之前，先手工构造一个标准的工具调用参数示例，在代码里把模型返回的参数解析一遍，看解析器会不会出错。这样做能快速排除解析层的bug。不同的框架对工具参数解析的容忍度不太一样，有些框架会在解析失败时静默丢参，导致模型那边看到的工具定义和实际不一致。

4.2 “agent execution terminated due to error”意味着什么

“agent execution terminated due to error.”是另一个高频搜索的报错信息。它和上面的“provider rejected”不同，这条更可能是Agent运行时本身的终止信号。

一般在代码里看到这个报错，说明Agent的执行循环被异常中断了，而且大概率不是模型API层面的问题。可能的诱因：

• 达到了最大迭代次数或最大Token限制，Agent循环被迫停止；
• 某个关键工具反复失败，触发了重试上限；
• 上下文窗口超长，或者引用了不存在的变量/工具名；
• 代码层面的异常未被捕获，比如文件写入失败、网络错误等。

面对这种情况，我的排查顺序是：

1. 先看执行日志的最后几行，确认是在哪个步骤崩的；
2. 检查是不是重试逻辑导致的死循环——有些Agent在工具失败后会重新规划，但如果规划逻辑有bug，可能每次都做出同样的错误决策；
3. 确认上下文长度。有些崩溃和“执行终止”表面无关，实际上是token超限导致模型输出被截断，间接引发的连锁反应。

如果你在用现成框架，建议打开框架的详细日志模式，执行轨迹会写得更完整。多花几分钟看日志，比在代码里瞎猜效率高得多。

4.3 LLM元评论残留：生成文本里混进“内心独白”

“llm元评论残留”这个热词虽然看起来有点学术，但实际上是很接地气的开发调试问题。它指的是模型在生成最终回答时，把不该出现的“内部思考过程”或“系统指令描述”留在了输出文本里。

比如你让Agent帮你总结一篇文章，结果返回了：

“好的，让我先分析一下这篇文章的结构，然后提取关键信息……总结如下：……”

前面的“好的，让我先分析……”就是元评论残留。

这类残留通常来自几个方面：

• Few-shot示例里带了思考链格式，模型学得过头，把思考过程也输出出来了；
• System Prompt里写了类似“你应该先思考再回答”的引导语，模型把它理解成“输出思考过程”；
• 模型本身的回答偏好，尤其在低温度采样时更容易完整输出推理链。

处理这个问题，我是三个方向同时做：

1. Prompt层：明确告诉模型“直接输出最终结果，不要输出分析过程”。可以在System Prompt里加一句目标输出格式的示例。
2. 后处理层：写一个简单的清理过滤器，把“让我先看看”“接下来”这类词开头的段落去掉。注意别误伤正文内容，所以规则要尽量精确。
3. 采样参数调节：适当降低温度（比如从0.7调到0.3），元评论出现的概率会明显下降。

如果你做的是面向终端用户的产品，这层清理绝对不能省。用户看到AI回答里混着推理过程，会立刻怀疑你是不是没调好。

5. 评测和质量保障：LLM as Judge和单元测试的落地姿势

5.1 LLM as Judge的偏差控制，不是把打分交给模型就完事

“llm as judge”是今天热词里少有的“评测方法论”类关键词。用LLM来对模型回答做评分，本身已经不是什么新鲜事，但真正把它用稳定的团队不多。

LLM as Judge最容易踩的坑是偏差：

• 位置偏差：同样的答案放在第一个和第二个位置，得分可能不一样；
• 冗长偏差：更长的回答有时候会被打得更高，尽管内容一般；
• 自恋偏差：如果待评测的回答风格和Judge模型自己爱输出的风格接近，容易得高分。

为了控制这些偏差，我建议在评测设计上做三件事：

1. 明确评分标准。不能用“回答好不好”这种模糊标准，最好给出5级评分锚点，每一级都有典型样例。
2. 多轮评测取平均。同一组样本多跑几次，或者用多个不同的Judge模型打分，最后取平均分，能削弱单一模型的偏好。
3. 洗牌评测顺序。尤其是对比评测（A/B测试），顺序要随机化，避免位置偏差被系统性放大。

另外一个容易被忽略的点是：Judge模型本身的质量。如果你拿一个能力不如被测模型的模型来打分，评测结果基本没有参考价值。先跑一批人工标注样本，看Judge的打分和人工评分的一致性，达到阈值再投入日常评测。

5.2 基于LLM的单元测试，从“自动写用例”到“自动改代码”

“基于llm的单元测试”也进了热词榜，这代表很多人在尝试用LLM来生成测试代码、甚至自动修复代码。

我之前在一个内部工具链上做过类似的实验，踩过的坑挺多的：

• LLM生成的单测用例设计得好的时候覆盖面很不错，但有时会生成大量重复、无效的用例，对代码覆盖率没有贡献；
• 断言逻辑往往偏“乐观”，测试通过率虚高——它可能只检查了返回值不为空，而没有验证具体值是否符合预期。
• 自动修复代码的最大问题不是“能不能修”，而是“修完之后会不会引入新的破坏”。

所以我现在用LLM做单测，采取的混合策略是：

1. LLM生成候选测试用例和预期行为描述；
2. 由程序做一次静态分析过滤，检查断言是否有效、用例是否冗余；
3. 实际跑测试，把失败信息提交给LLM分析，由它生成修复建议；
4. 修复建议由工程师人工确认后应用。

和“让LLM全自动改代码”相比，这套流程多了几步人工审查，但它能换来稳定性和可控性。自动化评测不是把代码质量的责任外包给LLM，而是把重复劳动压缩掉。

5.3 Agent项目评测：长链路任务的难点

和单轮问答评测相比，Agent项目的评测是另一个维度的事。Agent执行的任务往往有多个步骤，每一步都可能影响最后的结果。

做Agent评测时，我习惯把评测维度拆成两层：

• 过程层：Agent在每一步是否选择了合理的工具？工具参数是否正确？有没有绕了不必要的远路？
• 结果层：最终产出是否符合用户要求？格式、内容、准确度是否达标？

过程层这块，可以给Agent执行的每一步打标记，做成执行轨迹，然后用规则或LLM去判断轨迹质量。结果层则更偏向传统的评测方式，可以做人工回归，也可以用LLM做多维打分。

另外，Agent的评测很依赖测试任务的设计。任务不能太简单（测不出差异），也不能太复杂（复现成本太高）。我的做法是维护一个“难度梯度测试集”：从单工具调用、到双工具协作、再到多Agent协同，层层递进，每次改动都能看到具体是哪个层级回归了。

5.4 Spatial LLM和更复杂的评测维度

“spatial llm”出现在热词里有点意思。空间理解类模型出来后，评测维度也跟着扩展了——不仅看模型能不能“说对”，还要看它能不能“指对”“走对”。

空间LLM要解决的核心问题是让模型理解物理空间中的位置关系、距离和方向，比如“从A走到B，中间要绕过障碍物C”这类任务。这类能力的评测，和纯文本问答的逻辑完全不同，需要结合具体场景：

• 空间指令跟随率（模型能否根据空间描述执行正确路径）；
• 相对方位判断准确率（左、右、前方等）；
• 距离估算误差范围。

当Agent开始调用空间LLM做导航、操控机器人或管理物理环境时，评测就不只是“好”与“坏”的二选一，而是要精确到误差范围和安全边界。这个领域还在很早期，但值得留意。

6. 本地运行和轻量部署：安卓上跑GGUF模型的体验

6.1 为什么要把LLM塞进手机

“安卓本地运行gguf格式llm软件,支持安卓8”这个热词背后，反映的是本地化部署的长期需求。把LLM模型跑在手机里的吸引力很明显：数据不出设备、不需要联网、没有按Token计费的压力、在断网环境下也能用。

GGUF是llama.cpp生态里常用的模型格式，它把模型的权重和元数据打包成一个文件，便于量化和部署。一个7B级别的模型，用4-bit量化压到4GB左右，才能塞进现在主流旗舰手机的内存里跑；真要流畅运行，还得看手机本身的SoC、内存带宽和散热。

我能理解大家盯着“支持安卓8”的原因——安卓8（API 26）在今天已经算老版本了，但存量设备不少。如果要兼容这些老设备，就不能依赖太新的系统API和硬件加速特性，只能走相对保守的CPU推理路线。

6.2 安卓8跑GGUF的实机限制

我自己在几台不同年份的安卓设备上跑过GGUF量化模型，体验上的差异还是挺大的。这里把实际感受到的几个限制列出来：

• 内存是最大瓶颈。模型加载进内存后，系统如果频繁回收或触发交换，推理速度会暴跌。给小内存设备选模型时，尽量选3B或更小的模型。
• CPU推理与NPU的差距。新旗舰机有NPU和更好的能效核心，老设备只能纯靠CPU，一次推理耗时差距可能到好几倍。
• 量化等级与效果。Q4_K_M这类常见量化等级在平衡体积和质量上做得不错，但模型对中文理解、复杂推理的能力还是会有所下降，需要实际测试。
• 发热与降频。长对话场景下手机发热升温，系统会降频，推理速度会进一步下滑。手机上跑模型，不适合长时间高强度任务。

如果你手里正好有老安卓设备，我的建议是：装一个支持GGUF的本地推理App，选一个6B以内、Q4量化的通用模型，先跑几轮简单对话和总结任务，体验一下再决定值不值得为它调优。另外在系统中把App的电池优化关掉，不然后台推理很容易被系统杀掉。

6.3 LLM Studio等工具与本地Agent的想象空间

热词里的“llm studio”可能指代不止一个产品，但思路是一样的：管理本地模型、切换模型、做推理配置的工具集合。这类工具降低了普通人试玩本地LLM的门槛，不用写代码就能完成模型下载、参数调整、对话测试。

把本地运行和Agent结合，才是更有想象力的方向。比如：

• 本地模型 + 本地的文件管理Skill，做一个完全离线的工作助手；
• 本地模型 + 手机端的语音输入，做一个隐私性更强的私人记录Agent；
• 本地模型处理敏感文档，云端模型处理通用性问题，混合编排。

当然，目前手机端硬件的限制还摆在那里，本地Agent能处理的任务深度有限。但如果目标是“日常记录整理、摘要生成、待办提取”这类轻量任务，体验已经可以用起来了。我个人判断，这类本地轻量Agent适合做个人信息助理，重要文档和复杂任务还是放到云端模型或更大算力的机器上。

7. Agent学习路线怎么排：从概念到框架再到项目

7.1 先把“Agent是什么”和Token成本算清楚

“agent是什么”“ai agent token是什么意思”“agent开发教程”“agent开发学习路线”这些热词同时出现，说明又有一大批新人准备入场了。我先聊两个基础概念。

Agent是什么：可以简单地理解为一个“会用工具的智能体”。它的核心组件包括：大模型（决策大脑）、规划能力（拆解任务）、记忆（短期和长期）、工具调用（连接外部世界）。Agent和普通的ChatBot最大的区别就是：它不是只“说”，它会“做”。给它一个目标，它能自己设计步骤，逐步执行，根据中间结果调整策略。

Token是什么：Token是模型处理文本的基本单位，可以粗略理解为一个词或半个词。所有发给模型的文本——无论是用户输入、系统指令、工具定义、历史对话——都要换算成Token，按Token计费（不管是按量付费还是本地运行时的上下文窗口占用）。你在Agent上看到的“context length限制”，本质上就是能塞进多少Token的问题。

很多Agent项目做到一半发现成本失控，根源往往是：每一次模型调用都把大量历史上下文重复发送，Token消耗成倍增长。理解Token机制后，你就会注意：Agent循环设计要控制历史消息的长度，该压缩的压缩、该裁剪的裁剪，上下文管理是Agent工程化的基本功。

7.2 四步学习路径建议：提示词、框架、项目、工程化

我把Agent的学习路线归纳成四个阶段，每个阶段的目标和做法如下：

第一阶段：提示词与函数调用。先搞清楚LLM的函数调用（Function Calling）机制。从一个最简单的工具调用开始，比如让模型识别用户意图，然后返回一个JSON格式的方法和参数。这个阶段的目标是理解“模型并不是真的在调用函数，它只是生成了调用指令”。

第二阶段：跑一个现成Agent框架。选一个社区活跃的框架，照着官方文档把Demo跑起来。目标不是背API，而是搞清楚框架的执行循环怎么设计的：模型怎么获取消息、工具结果怎么被塞回上下文、什么条件下结束循环。

第三阶段：独立做一个真实项目。找一个自己能接触到的实际场景，比如写一个自动整理浏览器收藏夹的Agent、一个把网页转成Markdown存到笔记库的Agent。不用一开始就追求复杂，能跑通完整闭环最重要。

第四阶段：工程化打磨。把稳定性、日志、错误处理、评测、成本控制这些工程细节补齐。这个阶段才是真正拉开“会做Demo”和“能做产品”差距的地方。

每次有人问我“学Agent要不要先刷很多大模型理论”，我的意见是：先动手跑起来，遇到卡住再回头补基础。纯理论看再多，不如亲手跑通一个工具调用更有体感。

7.3 值得收藏的资源方向：LLM Wiki、Rust生态、聊天记录精调

热词里的“llm wiki”“基于rust语言ai agent”“使用聊天记录模型精调llm”，对应的是三个不同的学习资源方向，我给想往下钻的人指个方向：

• LLM Wiki类资源：现在社区里有不少人维护开源的LLM/AI Agent知识库，覆盖从模型选型、训练调优到部署推理的各类问题。建议把这类资源当成字典用，遇到问题去查，比从头到尾通读更有效率。
• Rust语言Agent开发：Rust生态里出现了不少Agent框架，Rust的优势在于内存安全和高性能，适合做对资源调度要求高的底层Agent运行时。想从工程底层理解Agent执行机制的，可以从Rust实现入手读源码。
• 聊天记录精调（SFT）：用真实聊天记录对模型做有监督微调，是让模型更贴合业务场景的常见手段。这里的关键是数据清洗——把用户消息、Agent回复、工具调用顺序都标好，标注质量决定了微调效果。不要直接拿原始聊天记录去喂，一定要做格式转换和噪声过滤。

另外，今天热词里还有“welcome to codex, openai's command-line coding agent”，说的还是OpenAI推出的命令行编程Agent。这类工具采用的是“在终端里通过对话生成代码、执行命令、处理错误”的方式，做开发辅助是真的高效——前提是你得习惯让AI直接操作你的终端，所以权限边界一定要设置清楚。想尝试的话，可以让它先从低风险任务开始跑，比如修单个测试失败、重构一个函数，逐步扩大它的权限。

我的整体感受是：Agent这个领域已经从“新奇玩具”慢慢变成“工程实践”，讨论的话题越来越具体——报错怎么查、Skill怎么设计、评测怎么做、手机能不能跑。这种转向其实是好事，说明真正做产品的人多了。如果你现在刚开始学Agent，抓住两个东西就够了：一个是把工具调用这个底层机制吃透，另一个是亲手做一个端到端的Agent项目。剩下的一切，都是在这些基础上长出来的。