一个真正投入生产的 AI Agent，通常要能连续工作数小时，使用几十甚至上千种能力，记住组织的工作方式，在安全边界内操作生产系统，并应对上下文长度限制。
它还要能通过不同平台和应用触达用户，例如飞书、企业微信、Slack、Teams、SaaS 工具或语音通话，并在这些入口之间保持一致。
要做到这些，模型周边的架构就和模型本身一样重要。这套架构就是 Harness（智能体运行框架）。
while not done:
response = llm(messages, tools)
execute(response.tool_calls)这是经典的智能体循环（loop）：把对话历史和工具交给模型，执行它提出的调用，然后重复。它至今仍是智能体的核心。
但到了 2026 年，一个成熟的 Harness 已经不只是这几行代码。
当 AI Agent 投入生产后，这段代码中的几乎每个词——消息、工具、执行，甚至循环本身——背后都依赖一整套子系统。这个循环依然存在，只是它已经不足以代表整个系统架构。
为什么 Harness 越来越重要
在 AI Agent 的落地实践中，我一直强调 Harness 的重要性。这里把这个观点展开说说。
可以用马和马具的关系来类比。强壮的马代表原始能力；马具决定这种能力能否被控制、指向目标，并且明天还能安全地使用。给马套上马具不会让它变聪明，却能让它真正派上用场。
AI 也是如此。前沿模型或许能推理复杂任务，但生产系统仍要决定：给模型哪些上下文、让它记住什么、允许它发现什么、向它开放哪些能力、如何执行操作、在哪里运行代码、使用哪些凭据、哪些操作需要人来确认、发生故障后如何恢复、长时间运行的任务如何熬过重启、如何观察和评估结果，以及用户从哪里接触这个智能体。
这些功能合在一起，就是 Agent 的 Harness。
更关键的是，我们可以把自己的要求写进这套框架里：模型带来智能，运行框架则带来规则、边界、流程，以及我们对“完成”的定义。工程规范与模型能力在这里相遇。
下面是一种简化的 Agent Harness 示意：
这不是唯一标准答案，而是一个思考模型，帮助我们理解生产级 Agent 的 Harness 由哪些部分构成、各自负责什么。
为什么行业也在关注 Harness
过去几个月，整个行业越来越明显地汇聚到同一种思路上，这也是我写这篇文章的原因。
以 Viktor 为例。它是一款集成在 Slack 或 Microsoft Teams 工作区中的 AI 助手。2026 年 5 月，它完成了由 Accel 领投的 7500 万美元 A 轮融资，并宣称能够连接 3000 多种工具。Viktor 的重点并非强调模型本身，而是让智能体几乎不增加安装成本，就能融入团队已经在使用的聊天工具。
在 9 月底的 DevDay 上，OpenAI 发布了 dots：可以持续运行、拥有自己的云端电脑、具备跨应用记忆和审批控制的智能体。你可以在 ChatGPT 里交给 dot 一个项目，接着在 Slack 或 Teams 中继续交流，也可以通过语音和它对话——它始终是同一个智能体。OpenAI 还强调，用户可以设定 dot 能做什么、什么情况下必须先询问；永久删除数据等敏感操作，则必须得到明确同意。
几周前，Meta 也发布了个人智能体 Muse，它运行在独立的虚拟机上，可以直接在 WhatsApp 中调用。
从架构角度看，这些产品有着相似的形态：入口可以是 Slack、Teams、WhatsApp、ChatGPT 或语音，但背后的 Harness 保持不变——身份、记忆、权限、沙箱和审批规则都一样。智能体之所以能在不同入口间切换，是因为它背后的运行框架也能随之迁移。
这正是本文的核心观点：模型是引擎，交互入口只是一扇门，而真正的产品存在于运行框架之中。
下面从工具发现、知识与记忆、任务执行、安全治理和系统评估几个方面，拆解生产级 Agent 的 Harness 设计。
1. 别把所有工具一股脑交给模型：让它按任务发现能力
第一个架构问题是：要把所有工具都交给模型吗？
可以想象一个企业 Agent 连接了飞书、企业微信、飞书云文档和网盘、阿里云、GitHub、Jira、Slack、Salesforce、Stripe、AWS、Datadog、ServiceNow、Notion、PostgreSQL，以及几十个内部系统。实际部署中，这可能意味着接入上百个 MCP 服务器，每个服务器又提供二三十种工具，很快就会累积成数千种可调用操作。
最直接的做法，是一次把所有工具都交给模型。有些系统在技术上确实做得到，但从架构角度看，这通常选错了抽象层次：为了找到当前任务需要的两种工具，不应该先让模型读完数千份工具说明。
这里首先要明确：Agent 思考和工作的基本单位应该是什么？ 是单次命令（command），还是一个代表明确意图的任务单元（operation）？
作者主张后者。Agent 应该围绕有明确意图的任务单元来推理并组织工作，例如“列出我们正在使用的阿里云服务”“计算本月云服务费用”或“创建一项后续任务”，而不是围绕底层命令或界面点击来思考。换句话说，抽象层次应放在任务层，而不是指令层。
糟糕的工具层设计只是照搬应用界面（比如 click_customer_tab()、press_export()）；好的设计则让工具指向有实际意义的工作。
任务单元（operation）代表要达成的意图；Agent 应该在这个层次上识别和组织用户的需求。
任务单元可以有三种实现方式。简单任务只需调用一个现成工具。比如，“我们正在使用哪些阿里云服务？”只需调用阿里云 MCP 服务器中的一个工具，无需专门编写流程。
更复杂的任务单元会涉及多个工具。例如，“按团队分类，并按照公司的标准格式计算本月云服务费用”就需要多个步骤，也对结果格式有要求。它可以用两种方式封装：
- 技能（skill）：用说明写清楚要按什么顺序使用哪些工具、如何汇总、结果采用什么格式，再由模型按要求调用工具或编写代码。
- 组合工具（composite tool）：在 MCP 服务器的代码中把多个步骤组合起来。Agent 只需调用一次，结果更可预测，策略层也能把它视为一个完整操作。
两种方式可以实现同一个任务目标，但执行机制和可提供的保障不同。许多流程最初会以 skill 的形式出现，等稳定并变得关键后，再“编译”为组合工具。
那么，能力（capability）又是什么？可以把它理解为按接入系统划分的能力边界，通常用来归组相关工具，也可以作为系统连接、身份验证和策略管理的单位。例如，aws、github、jira 可以分别代表对应系统的一组能力。对 Agent 来说，capability 还可以作为任务单元的元数据和筛选条件，帮助它找到相关工具，而不必逐一遍历所有目录。
能力（Capability）→ 按接入系统划分的能力边界，例如 aws、github、jira
工具（Tool） → 有明确输入格式的单一动作
技能（Skill） → 引用工具，并说明如何组合使用
任务单元（Operation）→ Agent 要查找并执行的工作，可由以上任一种方式实现有了这些区分，Agent 就能按需发现所需工具，而不用面对多个互不相通的目录。
还有两点很重要。
第一，每种工具的输入和输出格式只定义一次，也就是放在 MCP 工具定义里。Skill 不需要复制这些格式，只需通过 ID 引用工具；Skill 加载时，运行框架会解析这些引用，把相关定义放进模型的上下文。
第二，简单任务仍然可以走简单流程。比如查询“我们用了哪些阿里云服务”，搜索只返回一个工具，Agent 读取它的定义后直接调用。不经过 Skill、直接调用工具也应该是正常路径，而不是例外。
此外，系统也可以提供 list_capabilities()。用户往往不知道 Agent 连上了哪些系统，所以“你能访问什么？”本身就是一个合理问题。如果两个已连接的系统（如 Jira 和 Linear）都能创建任务，Agent 也应该看出请求有歧义，并询问用户要用哪一个，而不是擅自猜测。
MCP 为工具提供通信方式和接口规范；至于如何发现、组合、授权和执行任务单元，则由 Harness 决定。
2. 知识也要按需加载：别把所有技能塞进提示词
把“做什么”和“怎么做”分开，也有助于理清 Harness 的组成部分。
一种常见的区分方式：
记忆(Memory) → 我们知道什么？
技能(Skills) → 我们如何工作？
能力(Capabilities) → 我们能连接哪些系统？
工具(Tools) → 系统具体可以执行什么？
操作(Operations) → 智能体实际要完成什么？这些概念彼此相关，却不能互相替代。很多混乱的Agent架构，都是因为把它们混在了一起——比如把完整流程塞进工具说明，或把工具的输入输出定义塞进流程文档。
随着使用时间增长，Agent 的技能也会越来越多。成熟的智能体最终可能积累数百套工作流程：处理事故、管理发布、引导新客户、开展安全审查、制定迁移计划，或按边界、信任区域、数据流和故障范围进行架构审查。这些都不是 API，而是处理各类问题的流程知识，类似资深工程师长期积累的经验，也是初级工程师需要花几个月才能学会的东西。
如果每次都把所有流程放进提示词，就会重现工具过多带来的问题。更好的做法是让模型先看到简短的技能信息，例如名称和一句说明；只有任务确实需要时，才把完整流程加载到工作上下文里。
如果技能只有几十种，把名称和说明留在系统提示词中没有问题。但数量庞大、变化频繁的工具应该通过搜索来发现。按需加载不仅适用于能力，也适用于知识。
3. 记忆不是聊天摘要：要分层、检索和整理
记忆是最容易被做得过于简单的部分。常见做法是总结对话、存储总结，然后每次都把它塞进上下文。对小型系统来说，这样能用；规模扩大后就不行了。
更好的架构至少要区分三件事：工作上下文（当前窗口里有什么）、持久记忆（哪些信息值得留到以后）和记忆检索（如何在合适的时机找回相关信息）。对话本身不等于记忆；记忆是对话中值得留下的部分。
检索应该结合自动与主动两种方式。 在调用主模型前，Harness 可以自动把相关的项目偏好、过去的架构决策或组织约束放进初始上下文。
但自动检索无法预料所有需求，因此模型还应该有一个明确的 search_memory(query) 功能，让它在任务进行到一半、发现还需要额外信息时主动查询。例如，它可能需要知道团队给生产环境部署取名时遵循什么规范：
用户提出请求
↓
自动检索记忆 ──► 放入初始上下文
↓
智能体开始处理
↓
“我还需要更多背景”
↓
search_memory(...) ──► 找回更多记忆记忆整理应该是一条独立流程。 假设用户说：“我不再用 PlantUML 写架构文档了，以后改用 Mermaid。”把整段对话永久保存并没有意义。真正值得留下的是一条整理后的事实：“架构图统一使用 Mermaid，不再使用 PlantUML。”要得到这样的记忆，需要抽取、评估相关性、规范表述、去重和合并。这些工作不必挤在实时处理流程里，可以在一轮对话结束后异步完成，避免每次交互都额外耗时。
记忆还必须有明确的应用范围。 企业环境中，如果所有记忆默认全局共享，就会带来风险。用户记忆（个人偏好和工作习惯）、工作区记忆（团队规范、架构决策和职责划分）、任务或项目记忆（当前目标、中间发现和待解决问题）、技能知识（流程、经验和已知集成问题），它们的所有者和生命周期各不相同。个人偏好不应该悄悄变成组织政策；一个项目里的决定也不应该悄悄升级成全公司的规则。
记忆必须有明确的范围、来源、所有者和生命周期。光靠向量相似度，构不成一套记忆架构。
4. 检索之后还要筛选：Jev 只是其中一种选择
检索还有一个较少被讨论的问题。
假设记忆检索返回了 40 条候选内容，任务单元搜索又找出 25 个可能相关的工具，以及 12 个看起来和任务有关的技能。
检索只能回答“哪些东西可能相关”，却没有回答“哪些东西真正应该交给智能体”。
传统做法是使用嵌入向量（embeddings）、启发式规则（heuristics）、交叉编码器（cross-encoders）、重排模型（rerankers），再加上另一次大模型调用，或把这些方法混合起来。
2026 年，这个环节有一种值得关注的新选择：TypeSafe AI 推出的 Jev 等面向决策的模型。
Jev 并不是另一个用来聊天的大语言模型。TypeSafe 将它描述为一种用于快速结构化决策的“系统一”模型（System One Model，借用了丹尼尔·卡尼曼《思考，快与慢》中“系统一”的概念）：
输入背景信息和一个答案范围受限的问题，它返回类别、分数和概率，而不是一段生成文本。如果你用过带分类头的 BERT，会觉得它的形式很熟悉；不同之处在于，问题和分类标签可以在每次请求时定义，因此不必为每种决策分别训练一个分类器。
这种方式适合运行框架中的许多任务：
检索到的记忆 → 选择 / 重排 → 最终注入上下文的记忆
候选操作 → 筛选 / 评分 → 值得加载的操作
收到的请求 → 分类 → 路由 / 模型 / 策略信号Jev 目前公开测试的结果有好有坏。Parallel 的评估发现，Jev 在某些场景中能达到或超过他们训练的模型，但面对大量分类标签时表现吃力；至少一份公开实践报告则显示，Jev 方案并未胜过原有的向量检索基准。对你的场景来说，确定性规则可能更合适；专用分类器、交叉编码器、普通向量相似度，甚至一个小型语言模型也都可能更好。任何专用模型都应该用自己的数据评估。
更普遍的架构启示是：筛选不一定需要生成。 前沿推理模型不应该因为“能做”，就自动包办系统里的分类、路由、重排、相关性判断和策略评分。很多时候，运行框架应该先缩小决策范围，再让主模型处理：
Harness 需要不断做这类小决定：
该搜索哪个记忆空间？哪种能力和任务有关？应该加载哪个任务单元？哪些候选内容值得放进上下文？这个请求真的需要最强模型吗？
这些本质上是分类、路由、排序和筛选问题，而不是生成问题。
真正该问的不是“要不要加 Jev”，而是“这是生成问题，还是一个答案范围有限的筛选问题？”
判断正确，就能节省上下文容量、降低延迟和成本，让昂贵的推理模型把精力用在真正需要推理的地方。
5. 让代码处理重复工作：别让模型逐条编排调用
经典的 Agent 循环会在模型和工具调用之间来回切换。步骤不多时，这完全可行。
但如果要跨三个系统处理 500 条记录，让模型逐条安排每一次调用，就会又慢、又贵，也容易出错。
Agent 理解任务和可用工具后，可以改为编写程序：
customers = crm.search_customers(status="active")
results = []
for customer in customers:
invoices = billing.list_invoices(customer_id=customer.id)
overdue = [i for i in invoices if i.status == "overdue"]
if overdue:
results.append({"customer": customer, "invoices": overdue})整个流程变成：模型生成执行逻辑，沙箱通过程序调用工具，运行环境负责汇总和转换数据，最后只把结果交还给模型。大语言模型负责推理工作流程，Harness 负责重复、机械的执行。
一旦代码执行成为核心能力，沙箱就成了智能体的一部分。它不再是旁边附加的计算器，而是智能体真正的工作电脑，里面可以有文件系统、命令行、Python 运行环境、临时数据库、Git 仓库、下载的文件、生成的产物和工具代理。
这也解释了为什么 OpenAI 的 dots、Meta 的 Muse 和多数严肃的编程 Agent，都会给每个智能体配一台自己的云端机器。这和让大语言模型待在一个 REST 接口后面，是截然不同的架构。
6. API 优先，浏览器兜底
Agent 的 computer use 能力很强，很容易让人把它当成通用连接方式。但它不应该自动取代 API。如果智能体可以通过一次确定的 API 调用拿到发票，那么让它点开六个网页、一步步找出发票，显然更慢、更不稳定，也更难审计。
一种合理的能力优先级是：
结构化 API / MCP → 优先使用
代码执行 → 用于组合和转换
浏览器 / 电脑操作 → 作为后备，或用于只能通过界面操作的系统当系统没有 API、API 不完整、旧系统只提供界面、必须查看页面实际呈现的内容，或者任务本身就是操作界面时，浏览器才真正派得上用场。它应该扩展智能体的能力边界，而不是取代好用的软件接口。
7. 凭据不进模型上下文：每次执行都要过策略关
如果 Agent 能操作很多系统，凭据架构（credential architecture）就至关重要。错误做法是把 STRIPE_API_KEY、GITHUB_TOKEN 之类的密钥放到模型上下文附近。正确做法是让模型只表达意图，再由系统完成后续处理：
模型只需知道“我可以读取发票”，不需要知道“这是 OAuth 刷新令牌”。能力和凭据是两回事，必须分开管理。
策略也应该由同一个关口负责。智能体决定做某件事，并不代表这件事就应该被执行。search_customer() 和 refund_customer($18,000) 都可能是有效工具，但显然不能采用相同的执行规则。策略层可以按风险为操作分类：
读取 → 直接执行
低风险写入 → 执行并记录审计
敏感写入 → 先确认
破坏性 / 高影响操作 → 必须明确批准因此，真实的执行路径不是“模型调用工具”，而是：意图 → 任务单元 → 策略引擎 → 权限检查 → 风险评估 → 执行或等待人工批准。
OpenAI 为 dots 选择的正是这种模式：用户可以自定义规则，敏感操作必须征得同意。生产级运行框架可以参考类似设计。
8. 高风险操作由系统拦截，审批不能交给模型决定
假设 Agent 正在准备一次生产环境部署：服务是 payments-api，版本为 4.7.2，需要替换三个 Pod。较差的做法，是让模型在聊天里打出“要继续吗？”，然后希望它能正确理解用户的回答。
更好的方式，是由 Harness 发出一条结构化的待处理操作（pending action）。交互界面将它呈现为真正的“批准 / 拒绝”按钮；用户作出决定后，系统从暂停的执行状态继续运行。人在流程中不再是事后补上的界面功能，而是执行生命周期的一部分。界面不只是显示 Markdown，也参与了执行协议。这正是 MCP elicitation 和 MCP Apps 所支持的交互方式。
有一点尤其重要：是否审批，不能由模型自己决定。当高风险的 execute_operation 到达策略引擎时，Harness 就应该暂停任务并返回“待处理”状态，不管模型原本打算做什么。另一个独立功能 ask_human() 则供模型在缺少信息时使用：例如要统计哪个月份、两个已连接的任务系统该选哪一个，或“支付服务”指的是测试环境还是生产环境。
在短暂的同步聊天中，用户直接回复就够了；对于长期运行的后台任务，这种机制则不可或缺。任务可以保留当前状态并暂停，把问题送到合适的入口（例如 Slack 中的按钮、Teams 里的卡片），再从用户回答的地方继续执行。
从屏幕上看，模型主动询问和系统强制审批可能很相似，但它们属于不同的层级：前者是模型在补充信息，后者是系统执行策略。
9. 不同任务，选择不同模型
“不是每个决定都需要前沿模型”这条原则，同样适用于主模型。Harness 可以根据任务复杂度、风险、响应时间、成本和任务类型，选择快速模型、均衡型模型、前沿推理模型、编程模型、视觉模型或专用分类器。流程不必是“所有任务都交给最大模型”，而可以是“任务 → 分类 → 所需能力 → 选择模型 → 执行”。
很多应用并不需要动态路由，这完全没问题。但当智能体需要处理数千甚至数百万个任务时，模型选择就不再只是一个配置项，而会变成架构问题。
10. 智能体不该绑在某个聊天软件里
这也是当前市场正在显现的趋势。
许多 Agent 最初只是一个 Slack 机器人。后来有人问“能不能也放到飞书里？”，结果半个代码库都得重写。这说明通信入口和智能体运行环境耦合得太紧。
更好的架构是让每种通信渠道都成为同一个运行环境的适配器：
实际做法是，把不同渠道的事件——Slack 事件、Teams 活动、WhatsApp 消息、语音转写文本、API 请求——统一转换为一种内部格式：
{
"actor": "...",
"workspace": "...",
"conversation": "...",
"message": "...",
"attachments": [],
"surface": "slack",
"permissions": []
}Harness 只处理这种统一格式。输出时，入口适配器再把智能体的回应转换成渠道支持的形式：Slack 区块、Teams 自适应卡片、网页组件或语音回复。第 8 节提到的待审批操作，也可以在 Slack 中显示为按钮、在 Teams 中显示为卡片、在语音中提示用户说“确认”——操作和状态相同，只是呈现方式不同。
这正是 Viktor、dots 或 Muse 这类产品能够出现在用户常用工作环境中的原因。智能体可以换入口，而不必换“大脑”。 真正有价值的不是 Slack 机器人本身，而是持久的智能体身份及其背后的 Harness。
11. 长任务要能暂停、恢复，也不能丢状态
当智能体可以持续工作几分钟、几小时甚至几天时，另一个假设就不再成立：一次 HTTP 请求就等于一个智能体任务。
长任务需要可靠保存执行状态，包括目标、当前计划、已完成步骤、产物、待处理操作、审批、故障和检查点；还要能在不丢失信息的情况下，在“运行中 → 等待 API → 等待人工 → 恢复运行 → 已完成”等状态间切换。
此时，系统看起来更像工作流运行环境，而不是普通聊天机器人的基础设施。这并非偶然。现代智能体正逐渐变成控制环中嵌入了大语言模型的有状态分布式系统。 最新 MCP 规范中的后台任务和多轮请求，正是协议开始跟上这种现实的表现。
12. 记录执行轨迹，用评估持续改进系统
传统监控关注请求是否成功、耗时多久、有没有返回 500 错误。智能体监控需要知道的远不止这些：Agent 认为任务目标是什么？检索了哪些记忆？加载了哪项技能、选择了哪种能力、尝试了哪些操作？触发了什么策略、请求了哪些审批、运行了什么代码？哪里失败、如何恢复？整个过程花了多少钱？最终结果真的达成目标了吗？
可观测性的基本单位不再是一条请求，而是完整的执行轨迹。没有执行轨迹，调试智能体行为就只能靠猜。
这就自然引出了系统评估（evaluation，简称 eval）。Harness 本身会影响智能体的行为。改变记忆检索、工具说明、技能指令、模型路由、上下文压缩或审批规则，即使模型本身一字未变，最终结果也可能不同。因此，评估应该衡量整个系统，而不只是模型：
模型 + 上下文 + 记忆 + 技能 + 工具 + 策略 + 执行 = 智能体行为值得跟踪的指标包括：任务成功率、工具选择准确率、不必要的工具调用次数、策略违规次数、故障恢复成功率、延迟、Token 消耗、每个成功任务的成本、人工介入率，以及记忆检索质量。
执行轨迹支撑可观测性，可观测性支撑评估，评估再推动运行框架改进。真正显著的质量提升，大多来自这个循环。
把各个部分组合起来
下面是把所有部分放在一起后的完整思考模型：
最重要的一点是：模型位于架构之中，而不是架构位于模型之中。
把职责分开后，面向模型的接口反而会变得很精简：
search_memory(query)
list_capabilities()
search_operations(query, capability?)
load_operation(id)
execute_operation(id, args)
run_code(code)
delegate_task(task)
ask_human(question, options?)其中，发现所需资源主要靠三个功能：
list_capabilities 显示已连接哪些系统；search_operations 从工具、组合工具和技能中找出合适的任务单元；load_operation 则只加载需要的工具定义或操作说明。审批刻意没有列在这里，因为它不是由模型发起的调用，而是由 Harness 强制执行的规则。
这几个简单接口背后，可能有数百种技能、分布在几十个 MCP 服务器上的数千种工具、数百万条记忆、多个模型，以及 MCP 服务器、浏览器、数据库和云端环境。复杂性并没有消失，只是被放到了可以按需发现的抽象层背后，而不是塞进每一次模型调用里。比起不断往提示词里添加工具，这才是我认为更有意思的智能体扩展方式。
Harness 正在成为产品本身
AI 工程曾经是“应用 + 大语言模型 API”，后来变成“应用 + 大语言模型 + RAG + 工具”。
现在，它正在变成一套完整的运行框架：上下文管理、记忆、支持按需发现的任务单元目录、筛选、工具执行、代码运行环境、浏览器、模型路由、策略、身份、凭据、人工审批、持久状态、可观测性和评估；模型则接入其中。
模型依然极其重要。但相比重建模型周围的一切，换用另一个强模型正变得越来越容易。真正沉淀下来的，是系统的运营知识、权限、记忆、集成、工作流、安全边界、评估体系、用户体验和智能体身份。
换句话说，运行框架越来越像产品本身，而交互入口只是人们今天用来访问产品的地方。
这不是一份照抄即可的蓝图
这并不意味着每个 AI 应用都应该实现上面的一切。
如果应用只需要五种工具，任务也都很短、能同步完成，直接把这五种工具交给模型可能就是最合适的设计。如果系统没有需要长期保存的用户信息，就不必搭建复杂的记忆系统。如果简单的向量检索已经能提供很好的上下文，重排模型或决策模型可能只会增加延迟和维护成本。如果工作流完全不涉及重要操作，也没必要建立复杂的审批机制。如果一个模型已经能稳定处理所有任务，动态路由只会徒增复杂度。
架构应该由实际约束决定，而不是追逐潮流。
也要说明本文讨论的范围：这里描述的是一套高层次、相对精简的架构，也是适合公开讨论的部分。严肃的产品还会在此基础上构建很多自己的能力，例如排序方法、记忆启发规则、评估数据集、安全机制和编排细节。这些通常才是每个团队真正的竞争优势，也理应保密。
不过，当Agent变得持久、深度集成、支持多个入口、能够长时间运行并承担重要工作时，逐渐浮现的基本骨架是相通的，值得大家一起讨论。有些系统只需要其中 20%，有些则需要更多。
从更强模型到更完整的系统
Agent 工程中最有意思的变化，不只是模型变得更好，也是模型周围的系统变得更完善。
这种转变体现在：
- 从“应该给模型哪些工具？”转向“怎样发现合适的操作？”；
- 从“能塞多少对话历史？”转向“哪些信息值得成为记忆？”；
- 从“怎样检索相关上下文？”转向“怎样检索、排序、筛选，并只注入值得付费使用的上下文？”；
- 从“怎样写系统提示词？”转向“这项任务需要加载哪些知识？”；
- 从“怎样调用三个工具？”转向“要不要让模型逐个编排这些调用，还是直接写一个程序？”；
- 从“智能体能不能做这件事？”转向“它是否有权这样做、应该使用哪个身份和凭据、是否需要人工批准？”
我们也正在从“做了一个飞书机器人”，转向“做了一个可以通过飞书使用的智能体”。最后这个变化也许最重要。
结语：把模型智能变成可控能力
没有好马具，再强的马也难以驾驭。它可能跑得快、很聪明，甚至会给你惊喜。但生产系统不能建立在惊喜之上——它需要的是可控的能力。
现代 Harness 把模型的智能转化为一种能够持续运行、按需发现、实际执行、持续观测、跨入口使用并接受治理的能力。
模型负责推理；记忆保存知识；任务单元定义 Agent 要完成什么，技能说明怎样完成，能力连接真实系统。筛选机制先剔除无关信息，沙箱为智能体提供工作空间，策略划定边界，审批确保人类掌握控制权。交互入口是人们使用智能体的门，而 Harness 把这些部分连接起来。
评估下一套 Agent 架构时，别只问模型有多聪明，也要问：你围绕这种智能，究竟构建了怎样一套系统？