Photo by Quino Al on Unsplash

“ 从最简单的那一招开始练起”

智能体是2026年的一个热门话题。目前比较常见的一个说法是智能体=AI大模型+Harness。如果将AI大模型比作一个能力强悍的骏马，想要让这匹骏马服务于人且能够更快地驰骋，就需要有相应的驾驭工具，而这种驾驭工具在智能体中的体现就是Harness，有些人也称之为驾驭工程。

在我过去的数月过程中，对智能体的设计进行了一次实践。本次实践是基于数据的统计分析设计了一个智能体。在实践期间，一边伴随着行业发展与进步，另一边随着AI大模型的升级迭代，也让我在这个过程中对智能体的理解和使用有了更深的感触。虽然AI知识与实践日新月异，但是我依然觉得保留当下片刻的思考与总结，对于未来的我是一件很有意义的事。所以我想在此分享一下这数月的实践总结与思考。

01

—

什么是智能体

在2026年OpenAI没有发布那篇关于Harness的文章之前（详见参考文献[1]），我对智能体的感受非常模糊。最直接的感触是使用了Claude Code，只是感觉用这个工具确实比其他的编程工具更加强大。随后出现了Claude Code源码泄露，Codex迅速崛起等事件，让我从理论角度和实践角度对智能体有了更多的了解。

之所以称之为了解，是因为我觉得我对智能体的设计和定义还没有明确清晰的认知，所以不敢用理解这个词。在OpenAI发文以后，业界开始活跃的讨论Harness。由于我对Harness的了解有限，所以暂时不采用任何一个翻译。先让我们从几个常见的说法开始对智能体建立一个基础认知。

Agent = LLM (大脑) + Planning (规划) + Tool use (执行) + Memory (记忆)。

Agent = 模型 + Harness

这是两种比较多见的智能体定义。由于Harness工程目前没有明确的定义，且智能体本身就是一个宽泛的产品概念，所以我的理解是不管在何种定义中，辅助AI大模型基于目标高效完成目标任务的流程与工程，即为Harness。

如果我们使用普通的对话式AI进行编程，此时AI会缺少版本管理、阅读本地仓库、分支等软件工程能力。像Claude Code类的编程智能体则在此基础上完善了软件工程能力，并增加了会话内容持久化、任务规划、工具设计等功能，将AI编程从简单的脚本单文件开发进化成了工程维度的项目开发。

顺着这个角度出发，结合之前的两种关于智能体的定义，在智能体的设计上就有了一个更清晰的定义。不论是规划、执行以及记忆，还是Harness，智能体中以AI大模型为大脑，以工具、结构化流程为脚手架。除此以外，我特别赞同learn-claude-code（仓库地址见参考文献[2]）中的一个说法，援引如下：

构建 Harness。编写代码，为模型提供一个可操作的环境。这是我们大多数人在做的事，也是本仓库的核心。

Harness 是 agent 在特定领域工作所需要的一切：

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions  

Tools: 文件读写、Shell、网络、数据库、浏览器  

Knowledge: 产品文档、领域资料、API 规范、风格指南  

Observation: git diff、错误日志、浏览器状态、传感器数据  

Action: CLI 命令、API 调用、UI 交互  

Permissions: 沙箱隔离、审批流程、信任边界

模型做决策。Harness 执行。模型做推理。Harness 提供上下文。模型是驾驶者。Harness 是载具。

Harness是不同领域智能体运行的环境，这就意味着聚焦于不同领域的智能体拥有自己的Harness，就像learn-claude-code所举的例子：

庄园管理 agent = 模型 + 物业传感器 + 维护工具 + 租户通信

农业 agent = 模型 + 土壤/气象数据 + 灌溉控制 + 作物知识

酒店运营 agent = 模型 + 预订系统 + 客户渠道 + 设施 API

医学研究 agent = 模型 + 文献检索 + 实验仪器 + 协议文档

制造业 agent = 模型 + 产线传感器 + 质量控制 + 物流系统

教育 agent = 模型 + 课程知识 + 学生进度 + 评估工具

02

—

更进一步的智能体

在Harness概念被进一步讨论与定义以后，Harness工程的概念应运而生。很明显，Harness工程的工作，就是定义领域智能体的具体环境、能力。在我设计数据统计分析智能体期间，通过与Codex的gpt5.5对话讨论以及阅读两篇论文对智能体和Harness有了进一步的了解。两篇论文分别为参考文献[3]与[4]。

在参考文献3中，其有如此定义：智能体能力 = 模型能力 × Harness 能力 × 环境能力。

相较网络上流传比较多的说法，其有两点不同，一个是增加了环境能力，另一个则是能力之前不是相加而是相乘。如果说Harness是大模型的武器，那环境则是武器发挥的区域。比如说编程智能体中，环境能力就是代码仓库、测试能力、数据库等等组成的软件内容。环境能力是“这个世界本身是否足够适合智能体工作”，而Harness也可以更加进一步的阐述为“系统能不能让模型稳定完成任务，并产出可验证、可归因、可维护、可审计的结果？”。

可验证、可审计，是我在使用Codex开发数据分析智能体期间Codex经常强调的一点。AI大模型虽然强大，但是在无约束无引导的情况下，它会有很多自我发挥，不论是常见的幻觉还是对同一个任务在不同尝试中给出不同结果，都是它不可控的体现。所以智能体设计中，Harness工程很重要的一个环节则是需要帮助智能体的执行流程与结果能够可验证、可审计、可溯源，这样在智能体出错时才可以有依据的纠错与分析。

在此不直接使用两篇论文对Harness工程的说明与定义，而是就两篇论文以及我的实践，对智能体设计中的Harness进行介绍。

在设计某个领域的智能体时，需要基于该领域的工程化流程提炼和抽象能力，此时这些能力可以具象为智能体中的工具。此时智能体有了工具，但没有任何指引，会导致AI大模型并不能高效且明确的使用工具，此时可以通过提示词引导加结构化的工具注册使用流程约束，使得每一步都是系统工程化的操作，减少AI大模型犯错和不严谨的行为。为了让智能体的每一次流程不是一次性工作，而是会基于目标进行发展和实施，此时智能体还需要有合理的上下文。如何证明AI大模型自己说完成了任务，此时需要对每次操作都进行观测，而后通过证据驱动来验证，以达到结果可验证、可审计，此时需要的是智能体行为可观测。

综合两篇论文、以及对3月Claude Code源码暴露后的开源项目分析（详见参考文献[5]）与learn-claude-code教程的介绍，关于智能体的功能设计与组成我总结如下。

1.  智能体的底层是一个循环，以是否继续调用工具为判断依据，在循环的基础上需要定义符合业务需求的DAG（有向无环图，即不存在环路，一定会到达一个终点，可以理解为智能体的基础业务流程）；

2.  智能体由AI大模型驱动，以工具作为武器，通过工程化的工具注册使用流程约束，辅以提示词进行引导；

3.  流程的观测，证据化，用于结果的可验证与可审计，提升智能体的专业性和严谨性；

4.  会话内容的持久化，提示词设计以及业务知识等内容，便于智能体获取更加客观有效的上下文；

5.  基于业务的流程设计与能力设计，保证智能体的行为始终基于目标且足够专业。

以上只是我基于参考内容的简略整理，下面让我基于实际的项目实践来说明智能体设计。

03

—

数据统计分析智能体的实践

（一）需求背景

我的智能体名为“观澜”，具体可以看我的AI实践产品-观澜。这个智能体的目标是为了帮助缺少专业数据科学知识的人能够更高效地进行数据分析。对于非专业用户常见困难是：不知道该看什么指标、不知道数据够不够、不知道该用什么分析方法、不知道 p 值/相关性/因果的边界，也不知道结论是否可靠。

前文有提及learn-claude-code教程中的一个看法，每个领域的智能体能力是不同的。虽然很多人使用Codex、Hermes这样的通用智能体进行数据分析，但是这类通用智能体都存在专业深度完全依赖AI大模型且分析质量不够深入的问题。

于是基于以上的背景，我也尝试设计智能体进行实践，所以有了这个尝试。

结合背景，我对整个智能体的流程设计如下：

1.  意图识别

通过用户发送的内容作为上下文，判断用户的想法，作为后续给与分析建议、返回问题的依据。例如如果用户问请帮我分析一下这份文件，此时智能体会判断为是模糊意图，在此背景下智能体会先对用户提供的数据做一次清洗和预览，而后基于得到的数据信息给出分析方向推荐。通过类似的方式逐步引导用户完善自己的想法与需求。

2.  模式选择

因为非专业用户很多时候对问题或者目标是模糊的，有时候是想要寻找分析方法，有时候是想要咨询数据问题，有时候是不知道当前数据能做什么。基于意图识别之后，再根据意图进入不同的对话模式，避免每次都说一大堆或是强制分析，根本不考虑或满足用户的需求。

3.  分析入口门控

会对用户上传的数据进行清洗与预览，结合上下文与意图识别的目标，判断数据质量是否能够满足分析需求，给出的结论是否足够显著等保证结果严谨和专业分析。如果给的数据无法满足用户意图目标，则会进行反馈，提示用户补充数据或是引导进行其他支持的分析。

4.  分析状态机推进

进入真正的统计分析流程，调用内置的工具，基于之前的上下文制定具体的分析计划并执行。为保证分析结果可验证与可审计，对分析流程与产出物（图表、阶段性结论）进行证据收集与评估。

5.  合成策略

即给出分析或是回复结果。基于证据，对最终内容进行整理而后输出。

6.  后处理

将分析的内容持久化记录，作为知识、记忆系统的依据，便于用户后续查询分析产出物与内容。

（二）专业化设计

如果只是对简单的数据进行分析，其实使用通用智能体甚至是直接和AI对话分析也能获得结果。而分析的目标是多种维度、多个不同文件以及需要复杂流程的数据时，通用智能体和普通AI分析的局限性就是缺少扩展性且深度不足。

因为不针对统计分析这个场景，通用智能体和普通AI分析更像是一个问答机器，只是比一般的用户会写代码。例如意图识别、数据质量判断、证据收集等并不会那么深入。在强调专业分析和复杂分析的场景下，则有可能会导致分析深度不足或是内容质量不够高的情况。

根据我的流程，在此说明一下我的智能体设计思路，或者说是基于Harness工程的方向的设计想法。

1.  意图识别是区分与通用智能体的一个重要功能。因为这个项目的定位就是数据统计分析，所以意图识别可以从数据分析的角度来定义，所以这里使用LLM语义分类，对智能体无法区分意图的内容使用AI大模型来分析处理，而简单的则使用关键词匹配的方式快速识别。这也和下一步的模式选择息息相关。

2.  分析入口门控会根据清洗后的数据，从数据预览结果给出执行建议，是告知用户数据质量较低无法分析，还是可以执行后续操作，例如给出建议或是满足用户目标需求直接执行分析。这里保证的是必须基于用户给的数据给出后续操作，避免不支持的分析方法强制分析或是因为数据缺失、异常强行分析给出离谱错误的结论。

这里比较着重的设计的是智能体会分析多文件是否能关联，每个文件的维度是单一维度还是多维度，数据缺失以及异常情况，通过这些信息的清洗整理给后续步骤提供依据，避免AI大模型太过发散给出不合理的分析和结果。

3.  状态机推进即真正的分析流程，这里除了常规的分析方法、分析剧本（playbook）和工具设计以外，最值得一提的是证据收集。证据有两个作用，一个是作为支撑观点、结论的依据，另一个则是项目本身还有一个基于日常分析自学习生成记忆，再通过确认高置信度记忆生成知识的知识记忆系统，这个系统的学习依据也是证据。证据会标记来源的会话、相关的数据源，保证可以溯源。后续所有的分析结果、结论、观点为何得来都依赖这些证据，而非完全通过AI大模型自行分析整理，以此来保证分析结果的可验证、可审计。

4.  合成策略这一步即结果输出，除了常规的基于流程、证据给出结论以外，我在这里还额外设计针对非专业用户的业务分析。如果AI大模型通过分析得出了一些结论，提示词中会引导给出用户一些“So what”（这能说明什么）的说明，有证据支持且具有统计显著性的结果还会给出一些业务解释、建议以及下一步建议。同时如果有些结果没有证据支持，此时会要求说明结果的可靠性、置信度，避免因数据结果不可靠被误解引用。智能体面向非专业用户，会主动澄清分析目标、解释统计术语、提示数据缺口。在分析结果的质量保证设计上，我通过提示词引导当证据充足或者结论显著时，可以给出多个结论的对比分析以及对抗式假设，以验证给出的结果足够严谨。智能体会约束结论强度，避免把相关性说成因果、把探索性发现说成确定结论。

5.  参考两篇论文以及Codex给出的建议，从数据清洗、预览到得出数据质量，再到分析方向、路线、风险等都可监测，保证了结果的可验证和可审计。这些则是在开发过程中学习到的。

以上是基于数据统计分析这个场景，我所设计的“脚手架”，因为我依然不太明确Harness工程的定义，所以我不愿将其称之为Harness。

04

—

需求回顾与反思

最开始我是参考Claude Code的结构设计了MVP版本，在最初的半个月，整个智能体的表现其实更像是一个编程智能体。在我测试初期，因为后续的很多诸如证据、行为观测、结论的对抗式假设验证等重要的数据分析流程没有加入，每次分析都很随意，完全靠AI大模型自由发挥。期间甚至出现了我上传了时间维度的充值数据，智能体返回了用户画像，但数据中完全没有任何用户信息。后来发现问题以后，我让AI大模型解释，AI大模型的解释是因为发现上传的数据是充值记录，而后就推断为可以做用户充值分析，继而推断可以做用户画像。接着在完全没有用户维度数据的情况下，捏造了用户画像和推荐分析方向。

这是缺少工程化流程约束导致的情况，不能完全归咎于AI大模型的幻觉问题。也是因为这个例子，在后续的一个多月的时间里，我一直在做的就是学习怎么通过智能体Harness工程的思路提升分析的严谨性和专业性。

期间我还根据腾讯开源的一个记忆插件和Hermes agent的思路设计了第一版自学习记忆和知识系统，只不过还没有完全可用，在此不多赘述。

总体而言，从模仿Claude Code到基于实际领域场景完善功能，虽然底层的智能体循环大同小异，但是在此之上的工具设计、流程设计却是门道颇深。在此也引发了我的诸多思考。

1.  需求必要性反思

前文介绍了非常多我基于数据统计分析这个场景的设计，但是并没有说这个智能体最终反馈如何。根据我自己的使用以及周围朋友的反馈来看，能用，但是并没有显著优于其他通用智能体。

核心原因在于简单的数据分析，在AI的各类产品中结果差异不大；复杂的分析通用智能体也已经能做，虽然未必足够深入，但是也已经能帮助到用户，对于非专业用户而言他们也难以判断分析质量的高低。在这个背景之下，我的智能体带来的边际效益其实并不高。

除了非专业用户，对于拥有专业数据科学知识的数据分析师而言，他们从获取数据到分析方法制定的能力并不会比我的智能体差，且其中需要写代码进行分析的步骤他们靠一般的AI也能实现。诸多因素影响下，导致我的智能体定位其实很尴尬。

由此引发了我一个认真的思考，也是产品经理的经典问题，用户真的需要这个吗？

除了这个经典的问题以外，还有则是智能体是否必要的边界线在哪？似乎任何领域都可以说设计一个智能体。如果说智能体是类似网站、APP这样通用的载体，那么这么说不错。如果智能体是需要高度专业内容去设计流程、框架、工具的产品，那么很多领域以及业务其实并不需要设计智能体，就目前来看我所设计的数据分析智能体就是一个例子。

智能体在需求依赖高度专业的技能之时，价值会最大化，因为这需要高级且专业的思维和判断，这个方向中人要做的是方向制定，智能体可以显著提升其中专业度较低的工作效率。而如果一项工作本身专业高度有限，更偏流程化，智能体并不是最好的选择，这时候降级为一些自动化程序或是流程化的软件产品即可，不需要大费周章的设计为智能体。

2.  智能体的设计核心

（1）循环

此图援引自learn-claude-code教程

从learn-claude-code教程以及其他教程中可以看到，智能体的底层是一个循环。在此之上，需要基于领域与业务定义工具。为了让智能体能够更专业高效的使用工具，此时要更精细化的定义工具说明、工具注册，定义符合业务的DAG。比如我的智能体中从数据清洗开始为了保证结论可靠性的证据、检测、统计专业分析，Claude Code中的权限管理、代码的修改方式与Git工具等等，都是基于特定领域的业务场景设计的工具或者流程。

（2）按需设计智能体与子智能体

在截止到2026年6月，智能体有了多子智能体、子智能体并行执行这样的更高效发展。但是这依然要基于智能体所在的领域与业务而定。我的智能体在数据统计分析领域，在设计之初我和ChatGPT讨论时，GPT强调了数据统计分析的流程是典型的线性流程，此时子智能体的设计方式并没有用，并不会显著提升效率。从流程上来看，数据分析的每一步都要基于前一步的结果作为参考，所以对比编程智能体可以多个子智能体同时执行，子智能体的设计并没有太大的意义。

（3）行为观测追踪与结果的验证、审计

本文参考的两篇论文中均提及且强调了智能体执行结果的可验证、可审计，也是本文一直在说明的一点，是智能体区别于对话式AI结果的重要特征。智能体是一个基于目标的循环，在最近Antropic员工的分享中也提及了使用loop来完成目标（即告知智能体目标，以目标为终点循环智能体直至达成目标），思路和智能体其实基本一样了。说的再直接一点就是，智能体是一个以目标完成为导向的流程。那么怎么证明目标完成呢？此时就需要对完成的结果进行评估与验证，为了保证其不偏离目标就需要对流程中的工具调用、阶段性结果进行观测记录，以此作为结果评估的依据。这就是我的智能体中证据功能的主要作用。在我参考的参考文献4中，其针对编程智能体做了一次测试，在编程智能体中对结果有显著影响的是工具、长期记忆与中间件。如果缺少对这种关键因素的追踪，智能体的错误排查、结果验证则会更加不可靠。所以对智能体的工具调用、记忆这些行为基础元素观测追踪至关重要，也决定了智能体的结果质量。

（4）提示词是引导而非约束

在我设计智能体的过程中，提示词扮演了并不是特别重要的角色。我选择了按需加载提示词的方式，避免上下文膨胀以及无意义的提示词注入。由于提示词并非AI大模型百分百会遵守的规则，大多时候就算强制约束，AI大模型也有可能会不遵守。如果依赖提示词来约束AI大模型行为是不合理的，Codex曾给过我很好的反馈：我们应该用工程化的专业流程来约束，而非靠堆积提示词。提示词更多的是在模糊地带进行说明、引导，对工具给予更明确的要求。所以提示词是路标，而工程化的严谨流程是路沿。

（5）智能体是替代还是互补

对于智能体的预期是替代人还是与人的能力互补，是两种完全不同的思想，也决定了智能体最终的设计终点。如果是替代人，那么当前的AI还无法完全达到，如果是能力互补，那么这更考验的是使用智能体的人。

如果人使用智能体代替自己思考，觉得智能体无所不能，大概率就会错上加错，也无法提升人的上限。因为AI大多时候是顺着用户的想法沟通，如果不引导模型主动质疑用户的假设，那么除了在模型明显觉得不合理的时候，它通常会遵循用户的想法。另一方面，AI如果提出了质疑，但是人无法合理判断是否合理，本身也是一个极其大的风险。

所以不要依赖AI帮助自己思考和理解，这两件事依然要靠自己。

（6）Function call、MCP、Skill等等等等

在当前的智能体领域，各种专业名词层出不穷，但是未必都需要加入。技术在与时俱进，也许今天流行的，明天就被淘汰了。更重要的是保护好自己的注意力，选择当时判断最有效的手段，而非追逐热点。

（7）智能体的未来也许是长期记忆

不论是哪家智能体，现在都在着力于解决长期记忆。就算是我的智能体，我也设计了一版能自学习成长的记忆系统，而且还会根据记忆自己抽象为知识。然而我在实践以后更深刻的感受到，长期记忆和知识功能的设计依然任重道远，也是我目前浅尝辄止的原因。

长期记忆缓解了AI本身在上下文有限的情况下，在超过上限时无法完全回顾之前的上下文出现遗忘的问题。虽然像Claude Code和Codex有上下文压缩功能，但压缩就意味着损失。所以如果有稳定的长期记忆，则能有效地提升各类工作的效率。就目前来说，智能体的上下文管理是最值得去思考改进的方向。

（8）用哪些上下文

用户消息，文件信息，AI大模型思考结果，等等等等，智能体中会有非常多的上下文，如果一味全部纳入每次对话的上下文，要么超限，要么无用信息占据空间污染上下文。所以哪些要纳入上下文，哪些可以选择性加入上下文是非常重要的。在我的智能体中，每次数据预览结束后，并非将所有的数据都纳入上下文，而是将数据预览的数据整理结果、抽样前几十行纳入上下文，避免光是读数据文件就超出上下文。同样的在工具调用的过程中，会有非常多次的工具调用和结果返回，此时需要控制上下文预算，不可以让智能体无限制膨胀。这些都是需要结合智能体的业务来设计。

05

—

碎碎念

洋洋洒洒到此已有8000字，限于小子能力有限，难以讲清楚所有细节。如果对项目感兴趣，可以到我的项目仓库中探寻交流。

本次实践所耗费的精力与时间远超预期，奈何结果却是我自己判断这不会是一个需求性足够强的产品。但我想起那每个对着电脑思考的凌晨，看到未达预期甚至是结果倒退的晚上，以及看到目标达成的早晨，还有认真思考制定计划的下午，每一刻都弥足珍贵。

项目仓库：https://github.com/dreamrains/kratos

参考文献

[1] OpenAI. Harness Engineering: Building Reliable AI Agents[EB/OL]. (2026-05-15). https://openai.com/index/harness-engineering/

[2] shareAI-lab. learn-claude-code: A Tutorial & Harness Framework for Claude Code[GitHub repository]. (2026). https://github.com/shareAI-lab/learn-claude-code

[3] Chen, L., et al. AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents[J/OL]. arXiv preprint arXiv:2605.13357, 2026. https://arxiv.org/pdf/2605.13357

[4] Wang, Y., & Zhang, Q. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses[J/OL]. arXiv preprint arXiv:2604.25850, 2026. https://arxiv.org/pdf/2604.25850

[5] Zread. Clwa Code[EB/OL]. (2026). https://zread.ai/instructkr/claude-code

Photo by Quino Al on Unsplash

“ 从最简单的那一招开始练起”

智能体是2026年的一个热门话题。目前比较常见的一个说法是智能体=AI大模型+Harness。如果将AI大模型比作一个能力强悍的骏马，想要让这匹骏马服务于人且能够更快地驰骋，就需要有相应的驾驭工具，而这种驾驭工具在智能体中的体现就是Harness，有些人也称之为驾驭工程。

在我过去的数月过程中，对智能体的设计进行了一次实践。本次实践是基于数据的统计分析设计了一个智能体。在实践期间，一边伴随着行业发展与进步，另一边随着AI大模型的升级迭代，也让我在这个过程中对智能体的理解和使用有了更深的感触。虽然AI知识与实践日新月异，但是我依然觉得保留当下片刻的思考与总结，对于未来的我是一件很有意义的事。所以我想在此分享一下这数月的实践总结与思考。

01

—

什么是智能体

在2026年OpenAI没有发布那篇关于Harness的文章之前（详见参考文献[1]），我对智能体的感受非常模糊。最直接的感触是使用了Claude Code，只是感觉用这个工具确实比其他的编程工具更加强大。随后出现了Claude Code源码泄露，Codex迅速崛起等事件，让我从理论角度和实践角度对智能体有了更多的了解。

之所以称之为了解，是因为我觉得我对智能体的设计和定义还没有明确清晰的认知，所以不敢用理解这个词。在OpenAI发文以后，业界开始活跃的讨论Harness。由于我对Harness的了解有限，所以暂时不采用任何一个翻译。先让我们从几个常见的说法开始对智能体建立一个基础认知。

Agent = LLM (大脑) + Planning (规划) + Tool use (执行) + Memory (记忆)。

Agent = 模型 + Harness

这是两种比较多见的智能体定义。由于Harness工程目前没有明确的定义，且智能体本身就是一个宽泛的产品概念，所以我的理解是不管在何种定义中，辅助AI大模型基于目标高效完成目标任务的流程与工程，即为Harness。

如果我们使用普通的对话式AI进行编程，此时AI会缺少版本管理、阅读本地仓库、分支等软件工程能力。像Claude Code类的编程智能体则在此基础上完善了软件工程能力，并增加了会话内容持久化、任务规划、工具设计等功能，将AI编程从简单的脚本单文件开发进化成了工程维度的项目开发。

顺着这个角度出发，结合之前的两种关于智能体的定义，在智能体的设计上就有了一个更清晰的定义。不论是规划、执行以及记忆，还是Harness，智能体中以AI大模型为大脑，以工具、结构化流程为脚手架。除此以外，我特别赞同learn-claude-code（仓库地址见参考文献[2]）中的一个说法，援引如下：

构建 Harness。编写代码，为模型提供一个可操作的环境。这是我们大多数人在做的事，也是本仓库的核心。

Harness 是 agent 在特定领域工作所需要的一切：

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions  

Tools: 文件读写、Shell、网络、数据库、浏览器  

Knowledge: 产品文档、领域资料、API 规范、风格指南  

Observation: git diff、错误日志、浏览器状态、传感器数据  

Action: CLI 命令、API 调用、UI 交互  

Permissions: 沙箱隔离、审批流程、信任边界

模型做决策。Harness 执行。模型做推理。Harness 提供上下文。模型是驾驶者。Harness 是载具。

Harness是不同领域智能体运行的环境，这就意味着聚焦于不同领域的智能体拥有自己的Harness，就像learn-claude-code所举的例子：

庄园管理 agent = 模型 + 物业传感器 + 维护工具 + 租户通信

农业 agent = 模型 + 土壤/气象数据 + 灌溉控制 + 作物知识

酒店运营 agent = 模型 + 预订系统 + 客户渠道 + 设施 API

医学研究 agent = 模型 + 文献检索 + 实验仪器 + 协议文档

制造业 agent = 模型 + 产线传感器 + 质量控制 + 物流系统

教育 agent = 模型 + 课程知识 + 学生进度 + 评估工具

02

—

更进一步的智能体

在Harness概念被进一步讨论与定义以后，Harness工程的概念应运而生。很明显，Harness工程的工作，就是定义领域智能体的具体环境、能力。在我设计数据统计分析智能体期间，通过与Codex的gpt5.5对话讨论以及阅读两篇论文对智能体和Harness有了进一步的了解。两篇论文分别为参考文献[3]与[4]。

在参考文献3中，其有如此定义：智能体能力 = 模型能力 × Harness 能力 × 环境能力。

相较网络上流传比较多的说法，其有两点不同，一个是增加了环境能力，另一个则是能力之前不是相加而是相乘。如果说Harness是大模型的武器，那环境则是武器发挥的区域。比如说编程智能体中，环境能力就是代码仓库、测试能力、数据库等等组成的软件内容。环境能力是“这个世界本身是否足够适合智能体工作”，而Harness也可以更加进一步的阐述为“系统能不能让模型稳定完成任务，并产出可验证、可归因、可维护、可审计的结果？”。

可验证、可审计，是我在使用Codex开发数据分析智能体期间Codex经常强调的一点。AI大模型虽然强大，但是在无约束无引导的情况下，它会有很多自我发挥，不论是常见的幻觉还是对同一个任务在不同尝试中给出不同结果，都是它不可控的体现。所以智能体设计中，Harness工程很重要的一个环节则是需要帮助智能体的执行流程与结果能够可验证、可审计、可溯源，这样在智能体出错时才可以有依据的纠错与分析。

在此不直接使用两篇论文对Harness工程的说明与定义，而是就两篇论文以及我的实践，对智能体设计中的Harness进行介绍。

在设计某个领域的智能体时，需要基于该领域的工程化流程提炼和抽象能力，此时这些能力可以具象为智能体中的工具。此时智能体有了工具，但没有任何指引，会导致AI大模型并不能高效且明确的使用工具，此时可以通过提示词引导加结构化的工具注册使用流程约束，使得每一步都是系统工程化的操作，减少AI大模型犯错和不严谨的行为。为了让智能体的每一次流程不是一次性工作，而是会基于目标进行发展和实施，此时智能体还需要有合理的上下文。如何证明AI大模型自己说完成了任务，此时需要对每次操作都进行观测，而后通过证据驱动来验证，以达到结果可验证、可审计，此时需要的是智能体行为可观测。

综合两篇论文、以及对3月Claude Code源码暴露后的开源项目分析（详见参考文献[5]）与learn-claude-code教程的介绍，关于智能体的功能设计与组成我总结如下。

1.  智能体的底层是一个循环，以是否继续调用工具为判断依据，在循环的基础上需要定义符合业务需求的DAG（有向无环图，即不存在环路，一定会到达一个终点，可以理解为智能体的基础业务流程）；

2.  智能体由AI大模型驱动，以工具作为武器，通过工程化的工具注册使用流程约束，辅以提示词进行引导；

3.  流程的观测，证据化，用于结果的可验证与可审计，提升智能体的专业性和严谨性；

4.  会话内容的持久化，提示词设计以及业务知识等内容，便于智能体获取更加客观有效的上下文；

5.  基于业务的流程设计与能力设计，保证智能体的行为始终基于目标且足够专业。

以上只是我基于参考内容的简略整理，下面让我基于实际的项目实践来说明智能体设计。

03

—

数据统计分析智能体的实践

（一）需求背景

我的智能体名为“观澜”，具体可以看我的AI实践产品-观澜。这个智能体的目标是为了帮助缺少专业数据科学知识的人能够更高效地进行数据分析。对于非专业用户常见困难是：不知道该看什么指标、不知道数据够不够、不知道该用什么分析方法、不知道 p 值/相关性/因果的边界，也不知道结论是否可靠。

前文有提及learn-claude-code教程中的一个看法，每个领域的智能体能力是不同的。虽然很多人使用Codex、Hermes这样的通用智能体进行数据分析，但是这类通用智能体都存在专业深度完全依赖AI大模型且分析质量不够深入的问题。

于是基于以上的背景，我也尝试设计智能体进行实践，所以有了这个尝试。

结合背景，我对整个智能体的流程设计如下：

1.  意图识别

通过用户发送的内容作为上下文，判断用户的想法，作为后续给与分析建议、返回问题的依据。例如如果用户问请帮我分析一下这份文件，此时智能体会判断为是模糊意图，在此背景下智能体会先对用户提供的数据做一次清洗和预览，而后基于得到的数据信息给出分析方向推荐。通过类似的方式逐步引导用户完善自己的想法与需求。

2.  模式选择

因为非专业用户很多时候对问题或者目标是模糊的，有时候是想要寻找分析方法，有时候是想要咨询数据问题，有时候是不知道当前数据能做什么。基于意图识别之后，再根据意图进入不同的对话模式，避免每次都说一大堆或是强制分析，根本不考虑或满足用户的需求。

3.  分析入口门控

会对用户上传的数据进行清洗与预览，结合上下文与意图识别的目标，判断数据质量是否能够满足分析需求，给出的结论是否足够显著等保证结果严谨和专业分析。如果给的数据无法满足用户意图目标，则会进行反馈，提示用户补充数据或是引导进行其他支持的分析。

4.  分析状态机推进

进入真正的统计分析流程，调用内置的工具，基于之前的上下文制定具体的分析计划并执行。为保证分析结果可验证与可审计，对分析流程与产出物（图表、阶段性结论）进行证据收集与评估。

5.  合成策略

即给出分析或是回复结果。基于证据，对最终内容进行整理而后输出。

6.  后处理

将分析的内容持久化记录，作为知识、记忆系统的依据，便于用户后续查询分析产出物与内容。

（二）专业化设计

如果只是对简单的数据进行分析，其实使用通用智能体甚至是直接和AI对话分析也能获得结果。而分析的目标是多种维度、多个不同文件以及需要复杂流程的数据时，通用智能体和普通AI分析的局限性就是缺少扩展性且深度不足。

因为不针对统计分析这个场景，通用智能体和普通AI分析更像是一个问答机器，只是比一般的用户会写代码。例如意图识别、数据质量判断、证据收集等并不会那么深入。在强调专业分析和复杂分析的场景下，则有可能会导致分析深度不足或是内容质量不够高的情况。

根据我的流程，在此说明一下我的智能体设计思路，或者说是基于Harness工程的方向的设计想法。

1.  意图识别是区分与通用智能体的一个重要功能。因为这个项目的定位就是数据统计分析，所以意图识别可以从数据分析的角度来定义，所以这里使用LLM语义分类，对智能体无法区分意图的内容使用AI大模型来分析处理，而简单的则使用关键词匹配的方式快速识别。这也和下一步的模式选择息息相关。

2.  分析入口门控会根据清洗后的数据，从数据预览结果给出执行建议，是告知用户数据质量较低无法分析，还是可以执行后续操作，例如给出建议或是满足用户目标需求直接执行分析。这里保证的是必须基于用户给的数据给出后续操作，避免不支持的分析方法强制分析或是因为数据缺失、异常强行分析给出离谱错误的结论。

这里比较着重的设计的是智能体会分析多文件是否能关联，每个文件的维度是单一维度还是多维度，数据缺失以及异常情况，通过这些信息的清洗整理给后续步骤提供依据，避免AI大模型太过发散给出不合理的分析和结果。

3.  状态机推进即真正的分析流程，这里除了常规的分析方法、分析剧本（playbook）和工具设计以外，最值得一提的是证据收集。证据有两个作用，一个是作为支撑观点、结论的依据，另一个则是项目本身还有一个基于日常分析自学习生成记忆，再通过确认高置信度记忆生成知识的知识记忆系统，这个系统的学习依据也是证据。证据会标记来源的会话、相关的数据源，保证可以溯源。后续所有的分析结果、结论、观点为何得来都依赖这些证据，而非完全通过AI大模型自行分析整理，以此来保证分析结果的可验证、可审计。

4.  合成策略这一步即结果输出，除了常规的基于流程、证据给出结论以外，我在这里还额外设计针对非专业用户的业务分析。如果AI大模型通过分析得出了一些结论，提示词中会引导给出用户一些“So what”（这能说明什么）的说明，有证据支持且具有统计显著性的结果还会给出一些业务解释、建议以及下一步建议。同时如果有些结果没有证据支持，此时会要求说明结果的可靠性、置信度，避免因数据结果不可靠被误解引用。智能体面向非专业用户，会主动澄清分析目标、解释统计术语、提示数据缺口。在分析结果的质量保证设计上，我通过提示词引导当证据充足或者结论显著时，可以给出多个结论的对比分析以及对抗式假设，以验证给出的结果足够严谨。智能体会约束结论强度，避免把相关性说成因果、把探索性发现说成确定结论。

5.  参考两篇论文以及Codex给出的建议，从数据清洗、预览到得出数据质量，再到分析方向、路线、风险等都可监测，保证了结果的可验证和可审计。这些则是在开发过程中学习到的。

以上是基于数据统计分析这个场景，我所设计的“脚手架”，因为我依然不太明确Harness工程的定义，所以我不愿将其称之为Harness。

04

—

需求回顾与反思

最开始我是参考Claude Code的结构设计了MVP版本，在最初的半个月，整个智能体的表现其实更像是一个编程智能体。在我测试初期，因为后续的很多诸如证据、行为观测、结论的对抗式假设验证等重要的数据分析流程没有加入，每次分析都很随意，完全靠AI大模型自由发挥。期间甚至出现了我上传了时间维度的充值数据，智能体返回了用户画像，但数据中完全没有任何用户信息。后来发现问题以后，我让AI大模型解释，AI大模型的解释是因为发现上传的数据是充值记录，而后就推断为可以做用户充值分析，继而推断可以做用户画像。接着在完全没有用户维度数据的情况下，捏造了用户画像和推荐分析方向。

这是缺少工程化流程约束导致的情况，不能完全归咎于AI大模型的幻觉问题。也是因为这个例子，在后续的一个多月的时间里，我一直在做的就是学习怎么通过智能体Harness工程的思路提升分析的严谨性和专业性。

期间我还根据腾讯开源的一个记忆插件和Hermes agent的思路设计了第一版自学习记忆和知识系统，只不过还没有完全可用，在此不多赘述。

总体而言，从模仿Claude Code到基于实际领域场景完善功能，虽然底层的智能体循环大同小异，但是在此之上的工具设计、流程设计却是门道颇深。在此也引发了我的诸多思考。

1.  需求必要性反思

前文介绍了非常多我基于数据统计分析这个场景的设计，但是并没有说这个智能体最终反馈如何。根据我自己的使用以及周围朋友的反馈来看，能用，但是并没有显著优于其他通用智能体。

核心原因在于简单的数据分析，在AI的各类产品中结果差异不大；复杂的分析通用智能体也已经能做，虽然未必足够深入，但是也已经能帮助到用户，对于非专业用户而言他们也难以判断分析质量的高低。在这个背景之下，我的智能体带来的边际效益其实并不高。

除了非专业用户，对于拥有专业数据科学知识的数据分析师而言，他们从获取数据到分析方法制定的能力并不会比我的智能体差，且其中需要写代码进行分析的步骤他们靠一般的AI也能实现。诸多因素影响下，导致我的智能体定位其实很尴尬。

由此引发了我一个认真的思考，也是产品经理的经典问题，用户真的需要这个吗？

除了这个经典的问题以外，还有则是智能体是否必要的边界线在哪？似乎任何领域都可以说设计一个智能体。如果说智能体是类似网站、APP这样通用的载体，那么这么说不错。如果智能体是需要高度专业内容去设计流程、框架、工具的产品，那么很多领域以及业务其实并不需要设计智能体，就目前来看我所设计的数据分析智能体就是一个例子。

智能体在需求依赖高度专业的技能之时，价值会最大化，因为这需要高级且专业的思维和判断，这个方向中人要做的是方向制定，智能体可以显著提升其中专业度较低的工作效率。而如果一项工作本身专业高度有限，更偏流程化，智能体并不是最好的选择，这时候降级为一些自动化程序或是流程化的软件产品即可，不需要大费周章的设计为智能体。

2.  智能体的设计核心

（1）循环

此图援引自learn-claude-code教程

从learn-claude-code教程以及其他教程中可以看到，智能体的底层是一个循环。在此之上，需要基于领域与业务定义工具。为了让智能体能够更专业高效的使用工具，此时要更精细化的定义工具说明、工具注册，定义符合业务的DAG。比如我的智能体中从数据清洗开始为了保证结论可靠性的证据、检测、统计专业分析，Claude Code中的权限管理、代码的修改方式与Git工具等等，都是基于特定领域的业务场景设计的工具或者流程。

（2）按需设计智能体与子智能体

在截止到2026年6月，智能体有了多子智能体、子智能体并行执行这样的更高效发展。但是这依然要基于智能体所在的领域与业务而定。我的智能体在数据统计分析领域，在设计之初我和ChatGPT讨论时，GPT强调了数据统计分析的流程是典型的线性流程，此时子智能体的设计方式并没有用，并不会显著提升效率。从流程上来看，数据分析的每一步都要基于前一步的结果作为参考，所以对比编程智能体可以多个子智能体同时执行，子智能体的设计并没有太大的意义。

（3）行为观测追踪与结果的验证、审计

本文参考的两篇论文中均提及且强调了智能体执行结果的可验证、可审计，也是本文一直在说明的一点，是智能体区别于对话式AI结果的重要特征。智能体是一个基于目标的循环，在最近Antropic员工的分享中也提及了使用loop来完成目标（即告知智能体目标，以目标为终点循环智能体直至达成目标），思路和智能体其实基本一样了。说的再直接一点就是，智能体是一个以目标完成为导向的流程。那么怎么证明目标完成呢？此时就需要对完成的结果进行评估与验证，为了保证其不偏离目标就需要对流程中的工具调用、阶段性结果进行观测记录，以此作为结果评估的依据。这就是我的智能体中证据功能的主要作用。在我参考的参考文献4中，其针对编程智能体做了一次测试，在编程智能体中对结果有显著影响的是工具、长期记忆与中间件。如果缺少对这种关键因素的追踪，智能体的错误排查、结果验证则会更加不可靠。所以对智能体的工具调用、记忆这些行为基础元素观测追踪至关重要，也决定了智能体的结果质量。

（4）提示词是引导而非约束

在我设计智能体的过程中，提示词扮演了并不是特别重要的角色。我选择了按需加载提示词的方式，避免上下文膨胀以及无意义的提示词注入。由于提示词并非AI大模型百分百会遵守的规则，大多时候就算强制约束，AI大模型也有可能会不遵守。如果依赖提示词来约束AI大模型行为是不合理的，Codex曾给过我很好的反馈：我们应该用工程化的专业流程来约束，而非靠堆积提示词。提示词更多的是在模糊地带进行说明、引导，对工具给予更明确的要求。所以提示词是路标，而工程化的严谨流程是路沿。

（5）智能体是替代还是互补

对于智能体的预期是替代人还是与人的能力互补，是两种完全不同的思想，也决定了智能体最终的设计终点。如果是替代人，那么当前的AI还无法完全达到，如果是能力互补，那么这更考验的是使用智能体的人。

如果人使用智能体代替自己思考，觉得智能体无所不能，大概率就会错上加错，也无法提升人的上限。因为AI大多时候是顺着用户的想法沟通，如果不引导模型主动质疑用户的假设，那么除了在模型明显觉得不合理的时候，它通常会遵循用户的想法。另一方面，AI如果提出了质疑，但是人无法合理判断是否合理，本身也是一个极其大的风险。

所以不要依赖AI帮助自己思考和理解，这两件事依然要靠自己。

（6）Function call、MCP、Skill等等等等

在当前的智能体领域，各种专业名词层出不穷，但是未必都需要加入。技术在与时俱进，也许今天流行的，明天就被淘汰了。更重要的是保护好自己的注意力，选择当时判断最有效的手段，而非追逐热点。

（7）智能体的未来也许是长期记忆

不论是哪家智能体，现在都在着力于解决长期记忆。就算是我的智能体，我也设计了一版能自学习成长的记忆系统，而且还会根据记忆自己抽象为知识。然而我在实践以后更深刻的感受到，长期记忆和知识功能的设计依然任重道远，也是我目前浅尝辄止的原因。

长期记忆缓解了AI本身在上下文有限的情况下，在超过上限时无法完全回顾之前的上下文出现遗忘的问题。虽然像Claude Code和Codex有上下文压缩功能，但压缩就意味着损失。所以如果有稳定的长期记忆，则能有效地提升各类工作的效率。就目前来说，智能体的上下文管理是最值得去思考改进的方向。

（8）用哪些上下文

用户消息，文件信息，AI大模型思考结果，等等等等，智能体中会有非常多的上下文，如果一味全部纳入每次对话的上下文，要么超限，要么无用信息占据空间污染上下文。所以哪些要纳入上下文，哪些可以选择性加入上下文是非常重要的。在我的智能体中，每次数据预览结束后，并非将所有的数据都纳入上下文，而是将数据预览的数据整理结果、抽样前几十行纳入上下文，避免光是读数据文件就超出上下文。同样的在工具调用的过程中，会有非常多次的工具调用和结果返回，此时需要控制上下文预算，不可以让智能体无限制膨胀。这些都是需要结合智能体的业务来设计。

05

—

碎碎念

洋洋洒洒到此已有8000字，限于小子能力有限，难以讲清楚所有细节。如果对项目感兴趣，可以到我的项目仓库中探寻交流。

本次实践所耗费的精力与时间远超预期，奈何结果却是我自己判断这不会是一个需求性足够强的产品。但我想起那每个对着电脑思考的凌晨，看到未达预期甚至是结果倒退的晚上，以及看到目标达成的早晨，还有认真思考制定计划的下午，每一刻都弥足珍贵。

项目仓库：https://github.com/dreamrains/kratos

参考文献

[1] OpenAI. Harness Engineering: Building Reliable AI Agents[EB/OL]. (2026-05-15). https://openai.com/index/harness-engineering/

[2] shareAI-lab. learn-claude-code: A Tutorial & Harness Framework for Claude Code[GitHub repository]. (2026). https://github.com/shareAI-lab/learn-claude-code

[3] Chen, L., et al. AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents[J/OL]. arXiv preprint arXiv:2605.13357, 2026. https://arxiv.org/pdf/2605.13357

[4] Wang, Y., & Zhang, Q. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses[J/OL]. arXiv preprint arXiv:2604.25850, 2026. https://arxiv.org/pdf/2604.25850

[5] Zread. Clwa Code[EB/OL]. (2026). https://zread.ai/instructkr/claude-code