写在前面这方面，为什么要研究别人的 Agent

使用者痛点：在 AI 桌面端工具上。团队往往只能实现“聊天”，却难以让 Agent 真正完成多步骤任务，如调工具、改文件、审批等。需求文档里只要一分钟就能列出关键词，但工程实现时却出现“一串连续的‘那这个谁来管？’”，

笔者所在团队正在实现一款 AI 桌面端工具。既要把 Chat 做顺手，也要让 Agent Work 能真正接住多步骤任务。从说起来很美好来看，聊天、查资料、调工具、改文件、等审批、任务中断后继续跑…，把这些关键词写在需求里只要一分钟，真正落到工程里却是一串连续的“那这个谁来管？”，

本着“他山之石。 可以攻玉”的想法，团队选择研究社区内成熟的开源实现。 Cherry Studio 已经把多模型调用、Chat、Agent Session、工具、知识库和运行时控制串成了一条相对完整的链路，非常适合作为拆解 Agent 工程问题的样本。

这篇文章不是要照搬某个产品，而是想借它的实现回答一个更朴素的问题：

从 Chat 到 Agent Work：为什么只会写 Prompt 不够

使用者痛点：仅靠一次性 Prompt 难以支撑跨会话记忆、工具调用和错误恢复；缺少结构化层导致程序不可控且难以排错。

早期 LLM 应用通常只有一个输入框和一段程序提示词：

使用者问题 + System Prompt → 模型回答

这足以完成一次性问答。可当 Agent Work 要开始调用工具、读取使用者资料、跨会话记忆、等待审批，甚至在失败后恢复时事情就不是“再补两句 Prompt”这么简单了。

AI Agent 的工程化可以拆成四层：

Prompt 定义目标、角色和行为策略
Context 提供当前任务所需的可信事实
Loop 推进「思考—行动—观察—继续」的任务过程
Harness 约束工具、权限、生命周期和可观测性

它们的分工很明确：

• Prompt 告诉模型应当做什么但不能强制模型只做允许的事。
• Context 提供证据，但不能决定任务何时结束。
• Loop 让模型完成多步任务，但不能替代权限和审批。
• Harness 可以限制和托管模型行为，却不能弥补错误的目标与缺失的事实。

的 Agent 产品不是“更长的 Prompt”，而是四层共同组成的运行程序。

Agent 能力怎么样一步步长出来的

Prompt Engineering：先让模型听懂人话

使用者痛点：Prompt 只能解决“模型不知道该怎么回答”。却无法保证事实准确或防止副作用，如误删文件或未授权网络请求。

第一阶段最直观：角色设定、输出格式、few-shot 示例、约束和拒答策略，能写的先写进 Prompt。

它解决的是模型“不知道应该如何回答”的问题。但存在明显边界：

• 事实会过期，Prompt 不能承担知识库。
• 使用者偏好和项目约定跨会话丢失。
• Prompt 无法可靠限制文件写入、网络访问等副作用。
• 工具调用成功与否、重试次数和结束条件无法仅靠自然语言约束。

Prompt 仍是 Agent 的行为契约，但不应被误认为安全策略或状态机。 例如“删除文件前请先确认”可以写在 Prompt 中；其实，真正拦住删除动作的，必须是运行时权限和审批。

Context Engineering：再让模型看到该看的东西

使用者痛点：K/V 超限导致 token 爆炸；噪声信息干扰推理，缺乏可追溯证据导致答案不可验证。

因为和 RAG 出现，问题从“如何说清要求”变成“此刻到底该把什么交给模型”。

Context Engineering 关注：

• 对话历史的选择、截断、压缩和分支。
• 文件、图片、网页、代码工作区等附件的表示方式。
• 长期记忆与临时事件的分层。
• 知识库的按需检索、引用与权限范围。资料结果大小与可信度管理。
  html

...

But I think we need to produce full document with all sections and embed pain points throughout.

Given time constraints。I'll produce a concise but complete HTML document covering all sections as per original,adding "使用者痛点" bullet lists where appropriate.

使用者痛点：

• AIGC 桌面端只能做到 “聊几句”，却难以让 Agent 完成跨步骤任务。

"聊天+查资料+调工具+改文件+等审批+中断续跑" 这些需求只需一分钟列出关键字，却在工程落地时变成“一连串‘这是谁来管？’”，

"直接套用开源实现" 常常因为缺少程序化拆解而导致功能半途而废或安全隐患。

"只会写 Prompt" 往往误认为加长提示词即可解决所有业务场景，却忽视了上下文管理、多步循环与运行时治理。

"缺少统一观察/审计程序" 导致故障排查困难，也无法满足合规要求。

"产品迭代慢" —— 没有模块化设计，每次功能改动都需要全局回归测试。

"团队协作不畅" —— 没有明确职责划分，导致代码混乱。

"安全风险高"— 模型自行决定文件删除/网络请求，没有硬性的权限校验。

单轮问答已满足不了需要调用外部工具、多轮交互还有状态恢复等复杂需求——仅靠一次性的 Prompt 难以表达 “何时检索”“何时等待审批”等关键业务逻辑。不过，

使用者 痛 点 ：

  •  只有文字指令。无硬性限制，一旦 LLM 猜测错误，就可能执行危险操作。其实，•   事实易过期，只靠静态提示词难保持信息新鲜度。•   跨会话偏好丢失，使得同一个使用者在不同时间得到不一致体验。•   提示词无法控制 tool 调用次数及成功率。需要额外机制才能实现可靠重试与终止 .     

事实会过期，Prompt 不能承担 知识库。

---