我为什么做 Profer：从一个想法到真正可用的 Agent 工作台
有一段时间，我经常在不同的工具之间来回切换。
写代码时，需要一个聊天窗口；查资料时，需要打开浏览器；整理项目时，又要回到文件和终端。每个工具单独看都没有问题，但真正做一件完整的事情时，信息、上下文和操作总是被切成一小块一小块。每次换一个窗口，都像是在重新向工具解释一遍：我是谁、项目在哪里、刚才做到了哪一步、接下来应该做什么。
我开始想，能不能有一个地方，让 AI 不只是回答问题，而是能够理解当前的工作环境，围绕一个目标持续把事情做下去？
这就是 Profer 的起点。
我不想再做一个聊天窗口
最开始的想法其实很朴素：给 AI 一个更大的输入框，再接上更多工具，似乎就能解决问题。但真正使用之后，我很快发现，工具多并不等于好用。
一个 Agent 如果每次都从一张白纸开始，即使它拥有搜索、浏览器、文件读写和命令执行能力，也很难形成稳定的工作方式。它可能会完成一次任务，却很难在下一次继续接上之前的思路；它能够调用工具，却未必知道什么时候该读文件、什么时候该先确认风险；它能生成答案，却不一定能把结果整理成以后还能复用的东西。
所以，Profer 从一开始就没有把目标设成“让 AI 更会聊天”。我更关心的是另一件事：如何让 AI 成为一个能够在真实工作环境里持续行动的助手。
这也决定了 Profer 不只是一个聊天界面，而是一套围绕工作流组织起来的 Agent 工作台。
从 Proma 到 Profer：名字变化背后的事情
Profer 脱胎于开源项目 Proma，但它并不是简单换了一个名字。
在继续做下去的过程中，我越来越清楚地意识到，一个真正有用的 Agent 产品，需要同时处理几个层面的问题：模型如何思考，工具如何被调用，项目上下文放在哪里，长期经验如何保存，用户又如何控制它的行为。
这些问题如果分开解决，最后很容易变成一堆互相独立的功能。于是我开始把它们放在同一个产品框架里重新思考：模型是“大脑”，Skill 更像“手册”，预设则像“岗位”；工作区提供工作的边界，记忆负责保存值得复用的经验，而 Agent 负责把目标拆开、执行并验证结果。
这个过程让我意识到，产品的核心不是功能列表，而是这些能力之间的关系。
工作区：让 Agent 知道自己在哪里工作
我很看重“工作区”这个概念。
对人来说，进入一个项目目录，就意味着进入了一套具体的语境：这里有哪些文件，项目有什么规则，过去做过什么决定，哪些操作不能随便执行。对 Agent 来说也应该一样。
因此，Profer 会把项目规则、当前会话、工作区文档和相关技能放在清晰的边界里。Agent 不需要每次都从零猜测项目结构，也不会把一个项目里的临时信息轻易带到另一个不相关的场景中。
这看起来不像一个特别“炫”的功能，却是长期使用体验的基础。上下文有边界，行为才有依据；行为有依据，Agent 才不只是一个偶尔灵光一现的聊天机器人。
Skill：把一次做对变成以后也能做对
在使用 Agent 的过程中，我发现很多任务其实不是一次性的。
比如制作文档，有固定的检查步骤；操作网页，有一套安全边界；处理表格，需要遵守特定格式；发布文章，也有内容、排版和核验流程。如果每次都依靠临场发挥，结果就会不稳定，用户还要不断重复说明要求。
Skill 的意义，就是把这些可复用的工作方法整理出来。它不是一段普通的提示词，而是一份面向具体任务的操作手册：什么时候触发，先检查什么，哪些工具优先，哪里需要确认，最后怎样验证交付物。
这样一来，Agent 的能力不再只取决于模型本身，也取决于它是否拥有合适的工作方法。模型可以更换，工具可以扩展，但一套经过实际任务打磨的流程，会持续产生价值。
记忆不是聊天记录，而是值得留下的经验
我也花了不少时间思考“记忆”应该是什么。
如果把所有聊天记录都保存下来，那并不等于拥有了记忆，反而可能制造更多噪音。真正值得留下的，应该是稳定的偏好、已经确认的决策、重要的纠错，以及未来很可能还会用到的经验。
所以在 Profer 里，记忆需要被分类和维护。短索引负责告诉 Agent 去哪里找，具体主题再保存详细内容；项目硬规则放在项目规则文件里，跨会话经验放在记忆中，当前任务的临时过程则留在会话上下文里。
这种分层看起来有些“较真”，但它解决了一个很实际的问题：不是所有信息都应该被记住，也不是所有记住的信息都应该以同一种方式存在。
浏览器和工具：行动必须有边界
如果 Agent 只能生成文字，它更像一个顾问；当它能够读文件、运行命令、访问网页、填写表单时，它才真正开始进入工作流。
但能力越强，边界就越重要。
Profer 会尽量优先使用结构化的工具；需要操作动态网页时，再使用受管浏览器。浏览器操作遵循“先观察、再操作、操作后核验”的顺序，页面里的文字不会因为看起来像指令，就自动获得改变任务目标的权限。涉及发布、删除、发送消息或其他外部副作用时，也必须保持清晰的确认边界。
我不希望 Agent 只是“什么都敢做”，而是希望它能够分辨哪些事情可以直接推进，哪些事情需要停下来确认，哪些结果必须重新检查。这种克制同样是产品能力的一部分。
开发中最难的，不是把功能做出来
做 Profer 的过程中，最难的部分往往不是把一个按钮加到页面上，也不是让某个工具成功调用一次，而是让整条链路稳定下来。
一个任务从用户提出目标开始，到 Agent 理解上下文、选择工具、执行操作、处理异常、保存结果，最后向用户交付，中间任何一个环节不可靠，体验都会打折。更麻烦的是，Agent 的问题有时不是“做不到”，而是“做了一半却没有验证”，或者“完成了动作，却没有把结果整理清楚”。
因此，我越来越重视闭环：先取得证据，再下结论；修改之后重新读取或运行相称的检查；失败时说明实际状态，而不是用一句“应该可以了”掩盖不确定性。
这也改变了我自己做产品的方式。以前我可能更关注功能有没有实现，现在会更关心用户能不能知道它是否真的成功，下一次能不能沿用这次积累的经验。
Profer 现在是什么
如果要用一句话描述 Profer，我会说：
Profer 是一个把模型、工具、工作区、技能和记忆组织在一起的 Agent 工作台，目标是让 AI 从“回答问题”走向“持续完成事情”。
它可以是开发助手，也可以是内容工作台、资料整理助手、自动化执行者，或者一个懂得遵守项目规则的长期协作者。不同的工作可以使用不同的预设和 Skill，但它们共享同一个核心：让 Agent 在明确的环境里行动，并对自己的结果负责。
当然，它离“完美”还很远。Agent 仍然会犯错，模型仍然会误解，工具也会遇到权限、网络和页面变化。正因为如此，产品不能只追求更强的自动化，还要让用户能够理解、控制和修正自动化。
接下来，我想继续把它做得更像一个伙伴
我对 Profer 的期待，不是让它替用户做掉所有事情。
真正好的助手应该减少重复解释，帮助人保留上下文，在合适的时候主动推进，也在不确定的时候诚实地停下来。它应该能够记住有价值的经验，但不会把所有琐碎对话都变成负担；它应该拥有足够的行动能力，但不会把“能做”误解成“可以擅自做”。
这是一条需要不断打磨的路。每一次真实使用，都会暴露新的问题：某个流程为什么不够顺，某个 Skill 为什么没有正确触发，某条记忆应该放在哪里，某个自动化是否真的值得长期运行。
我想把这些问题一个一个解决，也把解决过程留下来。因为 Profer 不只是我正在开发的一个软件，它也在反过来改变我对“工具”“工作流”和“软件应该如何帮助人”的理解。
这篇文章算是一个阶段性的记录。
如果你正在使用 Agent，也许你会遇到和我一样的问题：真正让 AI 变得有用的，可能不是再增加一个模型，而是给它一个清晰的工作环境、一套可靠的方法，以及对结果负责的习惯。
而 Profer，正是我对这个问题的一次持续回答。
