L｜AS&A: Agentic System & Agent
仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
名字这样取是因为觉得好玩。写这个是为了梳理思想
这篇文章的大背景是最近身边很多人都在谈论agent，而且经常会听到这样的一个讨论：这是一个对话bot，不是一个agent，因为它主动性不够；或者说这个bot也有主动给用户发信息，所以它是agent。[1]这篇采访我很喜欢，Andrew提议不去纠结一个应用是不是“Agent”，而是去关注它有多“Agentic”。一个agent的落地，需要很多上下游才能够完成工作，所以本身叫做agenticsystem更合适。由于缺少一个名词，所以下面的论述中暂时统一用agent来表示。在当前日新月异的场景下，所有的定义都是阶段性的，所以当一个定义会被拿出来争论不休，那么搁置它，求同存异是最好的。因此，我希望梳理一个agent（agenticsystem）的内容，将一些重要的概念系统性梳理在本文中。
本文梳理的目标有三个：
梳理理解框架，系统关注agenticsystem落地的各个维度，并且可以快速跟进新的进展
帮助新人，以及我自己掌握agenticsystem，给定一个路径，方便系统思考，有助于将其落地
梳理当前进展的优缺点，发现新的机会
本文会分为几个章节：
介绍基本的背景概念，即本小节
Agenticsystem的设计：multi&singleagent，LLM以及其他模块的配合，E2E还是模块化。
Workflowornot：什么情况下搭建workflow，怎么搭建workflow，不使用workflow的话怎么办。
Evaluation：评估方式
Thoughtsofcases：一些场景下的简单思考，比如如何实现内容的个性化生产，agent如何“给用户下命令”或者“引导用户”。
Takeaway：TLDR。重点信息聚合。
首先，要clear一个定义。Copilot是一个场景业务性概念，是一个协同者，当用户在做一件事情的时候，有一个辅助在旁边进行工作，此时这个辅助就是copilot。而当我们单独看一个交给辅助的工作的时候，它本身就是一个单独的系统，对它本身而言就不再是copilot了，而系统内部可能是一个多模块的分工协同，里面的每个模块都是一个单独的agent。一个应用的构建，可能涉及到singleagent或者multi-agent，这个agent分为llm-basedagent，hard-codeagent以及humanagent三种。而多智能体构建出来的应用，或许我们可以叫做agent-basedapplication，而很多开源工作称呼自己为agentframework，因为可以基于它进行应用开发，给一个不一定恰当图。NOTE：目前属于每个人都有自己的称呼的时代，只要构建好自己对问题本质的理解即可。
讨论几个话题。一个单agent的系统构建，往往工程性更重，确定性更强。而multi-agent的构建，特别是multi-llm-based-agent的构建不确定性更强。所以在实际场景的应用中，我们需要根据自己所处的环境和要解决的任务来判断自己的技术路线。比如deepresearch这个功能，本身属于确定大领域内的不确定性工作，通过multi-agent的架构来完成工作毫无问题，基本存在部分agents工作重合或者返工，一方面不会有负面作用，另一方面也保留了更大的可能性（就像我们的工作中也会尽量让两个人工作有一定重合从而作为backup以及补充不同视角的信息）（https ://www. anthropic.com/engineering/built-multi-agent-research-system）而对于部分确定性的任务，特别是我最近被问到了两个事情：
心理咨询机器人，能不能让他按照某些流程/流派进行问答，不要被用户带跑
AI问答，能不能让他按照某种既定的方式回答，并且在合适的情况下做引导，回答我们希望让用户看到的内容这两个任务和research不太一样的是他们已经落实到了拥有既定运转逻辑，且依赖信息范围固定，即close-domain下，基于用户信息个性化应对的场景。在我看来，这两个就是完全不一样的实现方式。在做MVP的时候可以随便做，但一旦尝试PROD，技术方案的确定上是两种不同的思维：人类本身对system是有下限预期的，上限再高，如果下限不能确定则无法满足人类预期。我们可以想一想，上面两种场景下人类的的下限预期是什么样子的。
第二个话题则是系统设计，是否需要模块化，是否可以End2End解决一切。我认为整个系统中部分模块可以End2End，但整体依然需要模块化设计：
系统可维护性，可解释性以及人工介入性
模型更新带来的能力上下限变化，技术更新后系统需要进行模块化替换
业务增长需要的定制化能力增长，不能被技术迭代遇到的困难所阻碍
人机协同性设计。我认为这是一个演进的问题，某种意义上，人最终的归宿都是死亡，但是我们不会因为最终一定会死就忽略中间的活着。
第三个话题则是专家知识引入。人类已经沉淀了很多知识和方法论，那么是直接将非结构化知识输入给系统，例如直接将整本书输入，还是将其进行一定的结构化处理后输入。比如我们之前在讨论应该怎么选房子，在抛弃个人利益后，听起来是一个决策树，而不是一个概念性的文本。
诸如此类，我认为如何结合自己当前要处理的业务场景，考虑到系统未来的演进，业务的演进以及相关技术的演进，甚至成本和竞对，都是很关键的。
这里并不是在强行引入SOTA概念，用锤子找钉子，而是在讨论一种新技术的应用可能性。要明确的是，在过去自行车就可以满足我们最后一公里的行程，可能未来满足这个需求的方式是电动滑板。替换收益并不一定大，但一定会有自己的特点，需要自行判断。当一个事情的执行需要多角色配合的时候，注意是多角色而不是多人，只要你可以将这个事情拆分成为不同的角色，那么其中的某个角色就有大概率可以被agent充当。具体的实现方式可以参考下面的内容。
[1]https ://www. youtube.com/watch?v=4pYzYmSdSH4
可以简单的将s（single）和m（multi）两种方式类比成两种工作模式，超级单兵作战和多人协同作战。前者信息掌握在一个人手里，但是效果好坏会被其个人能力和信息处理带宽限制；后者人数更多，进行一定合理的分工后会放大生产力，但信息共享可能不充分会导致重复做工甚至互相矛盾。
而且还有一个有趣的问题，multi-agent是应该在工作开始之前就确定好teammembers还是在工作进行中动态确定。不考虑成本来分析一下。
这里我们核心要制定的是agent的角色，我们在这种场景下认为singleagent是multi-agent的特殊情况。其实这个角色确定的过程就是人工进行专家知识强干预的过程。平时大家在使用LLM的时候会下意识的给定一个身份假设，这就是你希望这个agent扮演的角色，也是你认为这样的角色能够最大程度的解决你的问题从而输入的先验假设。而后来的故事则是，大家开始尝试让LLM帮助进行身份prompt的设计。然后人类选择一个自己看起来不错的prompt作为LLM的prompt。ok，那么我们在看过很多autogpt类似的工作之后，自然而然就想到了，是不是这个身份prompt存在动态化的可能性。就像是我们可爱的人类在公司是摸鱼的牛马，在家是躺平的咸鱼，一定是两种不同的身份定义。
我们可以参照两个文章：（https ://cognition. ai/blog/dont-build-multi-agents#a-theory-of-building-long-running-agents）这个文章里面提到，不建议使用multi-agent。里面说到将一个任务break成两个subtask的例子，我认为是任务分解失败，且上下文设计不合理造成的问题。进一步论证我在之前无数次说到的，未来对问题的理解和建模将会是变得比现在更重要的关键性能力。里面提到了一些简单的线性做法来确保两个subtask之间可以共享信息，并且引入一个LLM进行上下文的关键信息压缩和传递，这是一种合理的思维。这里的核心是判断哪些信息需要共享，哪些不需要，如果人工不介入，那么此时就体现出来调度模块的作用。至少在当前，完全依赖调度模块会让人类失去掌控感，并不是目前应该采取的做法。somehow就像是公司的运转，如果每个人都需要了解所有的上下文才能工作，那很多事情都无法推行了。Anthropic也讨论了类似的问题，主要以open-endedresearchtasks进行了讨论。multi-agent系统对开放性的探索性任务有很强的作用，因为本身这个任务是非常强的信息检索与分析的事情，它可以浏览非常多的信息，并提供不同视角的想法。而在最终的生产中，也是非结构化信息生产，用户对这部分内容也是一个参考性依赖。两个case对比，上面文章中举出来的例子是一个“制造车间”类型的case，第二个举的例子是一个调研性质，多“实习生”广泛提供信息的场景，本身差异很大，不具备可比性。
一个问题究竟是用一个LLM-basedagenticsystem解决，还是在里面分为多个模块，使用multi-agenticsystem的方式来完成，需要根据实际情况来定，而不是一个固定的回答。完成这样的设计需要综合考虑成本，预期，任务复杂程度以及本身能力水平。系统越简单就越考验团队最高水平，需要能够满足系统长期迭代的诉求且不断触及最高优化水准，这样的系统里面基础的LLM的能力影响就会非常大，并且可解释和可扰动性会下降。好处则是降低多模块的误差互影响。而模块化设计是在降低对单一模块的能力上限的要求和依赖，通过组合的方式提升整个系统上限，通过合理的任务拆解可以广泛利用各种模型，增加系统可解释性，且容易做到单模块升级和替换。坏处则是可能造成各个模块的误差累积和影响。根据当前了解到的情况，当前的模型进展，理念设计都在飞速迭代，根据实际业务情况选择模块化设计，降低对单一模型进展的高依赖，增加人工介入的手段和系统可解释性会是一个更合理的想法。
针对不同问题采取不同的系统设计，这并不是一概而论的。多智能体系统可以通过合理的工程设计，测试以及上下游设计在很多探索研究性质的任务上表达出强大的作用，给人类以有力的帮助。而单智能体可以在相对确定的成本，独立快速的解决一个小型规模的问题。同时，agent的身份设计是一个值得讨论的问题，先验的设计本身是一种强有力的专家知识介入。而动态形成身份则依赖了模型的推理能力，在模型能力完善的情况下，依然需要非常强的上下文输入和约束条件的介入。不可否认的是，动态身份具有非常promising的未来。
本章节中涉及到的参考内容：https ://alliance. xyz/essays/single-agent-vs.-multi-agent
对任务进行分类，然后选择合适的方案。上述我们从agent的角度讨论了他们分别适合什么样的任务，本小节从任务的角度来讨论我们应该怎么理解问题并进行方案设计。有些任务流程是固定的，有些任务流程是open的，有些情况下二者混合存在，针对不同的任务应该选择不同的做法。探索性任务的意思是任务本身只有端到端的模糊性期望，对过程几乎没有追踪要求，只对结果有模糊性的要求。而Orientedtaskdialogue是有明确的任务完成诉求的，这个任务可能不仅要求的结果，也要求了过程。我们以心理咨询为例：
一个合适的心理咨询是有强制的流程要求的，需要完成用户基础信息采集，在访谈中要根据用户的特点选择一定的流派和流程，不要跑偏，并在最后达到一定的目的。这个就属于OTD的范畴，而且完成它就很适合通过固定流程workflow来进行。
而针对咨询过程中的某个点，比如一个销售同学因为AI的飞速发展不知道自己应该怎么跟进这个事情，整体很焦虑，在心里咨询的过程讨论到了AI的应用，为了缓和气氛，咨询师和同学畅想了AI的未来，在这个子任务中就是一个满足伦理条件下的开放性问题讨论，就不存在一个固定流程。如果无法确定自己的任务属于什么类型，此时就去找专家，获取专家知识。如果找不到，那么就open的去做，然后沉淀workflow。
我们这里谈论的workflow和Coze，Dify中设置的工作流类似，但具体的编排方式不一定是这些平台中的样子，也可能是通过代码实现的固定编码。workflow之所以存在是因为用户认为这样的执行方式是好的，期望可以在某个任务中不断遵循。这种执行方式，在过去我们主要称之为专家经验，而专家经验的呈现方式可能是文本，可能是视频，可能是“少许盐”，可能是“等到颜色变黄”，可能是“你感觉差不多的时候”，如何将这些专家经验通过合适的方式沉淀成为workflow则是另一个重要的话题。
知识->workflow：这个过程就是过去PM与研发的工作，将业务经验转化为产品设计与技术实现，只是由于一些平台的出现，这个工作可以减少对研发的依赖。可以想到的事情是，这个过程中PM接触的知识相比过去的业务会更加抽象和聚焦，而大环境下对PM的期望也包括了TA对非编程式workflow的设计。某种意义上，promptengineer的工作也属于这个范围。
workflow评估：直接进行端到端将workflow进行评估是一种想法，但这种想法的成本都很高。所以此时需要对workflow的每个步骤或者说模块进行评估，减少误差累积。而每个模块的评估需要结合具体的专家知识以及常规的算法评估知识进行。
workflow的自动生成：这就是大家最喜欢的环节。万物皆可自动化，由LLM来帮助生成workflow，经过用户的部分修改后上手。在这种情况下，存在“部分”与“全部”生成的情况，比如你可能需要一个快销行业的workflow，你恰好很懂肥皂但是不懂洗发水，那么需要LLM补充的是洗发水部分，但是肥皂部分要遵循你的知识。
workflow的协同编辑：这是我认为当前做的不好的地方。因为一个workflow制定好之后，我们是希望它可以被方便的修改，并且所见即所得的呈现给用户的。如何才能让一个专家很方便的将自己的知识沉淀为一个workflow当前依然是一个值得研究的问题。
这两个单词我都很喜欢，前者给我生命力和活力，后者非常贴合这里的场景。本身就是一个非常自由不确定的流程，仅为这次任务而存在。在这种场景下，最重要的就是我们对agent的工作流程不做强要求，甚至希望它不确定或者是我们可以接受它不按照既定工作流程推进。这两种情况会在不同的背景下发生，前者是我们主动期望agent做高方差的时候来突破用户的常规思维，后者只是我们对它的容忍度非常高以至于我们可以接受一切可能性。还有一种特例，当对自己当前的任务完全不知道怎么做，那么也会采取上述流程，不同的是，当我们有了一定认知之后，可以再进行调整。
成年人选择都要。结合二者的优点，在合适的时候选择合适的方案。无论是在workflow的某个节点里面选择Ad-hocprocess还是反过来偶尔触发固定的workflow，都是一种很明智的做法。在构建AI应用的时候，80分以后的提升才是整个旅程最核心的部分。就像开发一个MVP类型的玩具只需要技术研发人员黑客马拉松的两天，但最终上线的一个可靠生产系统可能需要大量的工程设计，任何一个错误的小细节可能会导致最终应用崩溃。稍微提一下vibecoding，是一个很有趣的事情，也可以在很多情况下提升生产力。只是说一个应用的生产上线并不只有coding这一件事情，还有大量其他的工作在做，我们很高兴看到了类似于youware这样的工作在推动，期待未来有更多好用的工作上线。
本小结参考了下面的内容[ 1]ASystematicSurveyofAutomaticPromptOptimizationTechniques
和过去我们常见的评估方式差不多，我们将其分为动态评估和静态评估。而详细的评估指标上，要分为任务性指标和体验性指标。任务性：一般来说有准确召回等在任务本身上的指标定义，即这个system是否达成了任务预期体验性：这往往在于对话型是否足够流畅合适，或者拟人性，人机交互友好性等非任务性指标，当然体验性指标，比如调性，情感等也会对任务性产生影响，但二者实际应用和优化有所差异。指标定义要根据所处场景进行，具体怎么计算指标以及进行评估有不同方式
静态评估指的是在固定的评估标准和数据集条件下，对系统进行性能测量。这类评估通常使用标准化的基准测试集，通过输入预设的对话上下文，观察系统输出并与参考答案或人工标签进行对比，从而获得一组量化指标，如BLEU、ROUGE、METEOR、BERTScore等。典型方法包括：
基于数据集的离线评估：使用如MultiWOZ、PersonaChat、DailyDialog等标准对话数据集，针对目标任务（如任务型对话、开放域对话）进行自动评分。
相似度打分：通过文本相似度（如BLEU）、嵌入相似度（如BERTScore）等度量生成回复与标准答案之间的接近程度。
多维度评分框架：在特定任务（如情感对话、知识对话）中采用多维指标（如准确性、丰富性、连贯性、风格匹配性）进行评估。优点：
评估过程高度可复现，便于不同模型间横向比较；
成本低，速度快，适合大规模自动化评测。局限性：
静态评估通常基于“静态”答案集合，难以充分评估系统的动态交互能力；
不能覆盖多轮上下文一致性、灵活应对用户变化需求的能力，因而对实际交互体验的预测能力有限。
动态评估强调对话Agent在与环境或用户持续交互中的行为表现，通过动态调整评估标准和策略，更加真实地反映系统的交互能力和用户体验。典型方法包括：
用户模拟器：基于Agent构建一个高质量用户模拟器，与Agent进行对话并根据交互过程给出实时反馈。
人机交互实验（Human-in-the-loopEvaluation）：通过真人用户与Agent多轮对话，收集交互数据，依据对话流畅性、用户满意度、完成率等维度动态评估。
LLM评判（LLM-as-Judge）：引入大语言模型作为裁判，动态根据对话上下文和场景变化调整评分标准和反馈。裁判的训练可以依赖zero/few-shot或者学习人类裁判。
用户真实反馈：通过监控指标（正确率、失败率、平均交互轮次等）和日志分析来发现缺陷。建立持续反馈机制——将用户评价、错误样本反馈给系统，然后进行优化。示例：对抗式交互评估（AdversarialInteractionEvaluation）：构建一个“对抗智能体”作为用户角色，主动设计挑战性问题（如模糊请求、逻辑矛盾、长尾知识等），驱动对话Agent在交互中暴露潜在弱点。同时，配置一个“裁判智能体”实时对Agent回复的正确性、鲁棒性、灵活性进行动态打分。这种方法能有效测试系统在开放环境中的稳健性与泛化能力，推动Agent的持续优化。优点：
评估过程更贴近实际交互，能动态发现系统缺陷；
有助于探索系统的泛化能力、鲁棒性、对复杂用户行为的适应能力。局限性：
实验设计复杂，成本高，数据收集和标注工作量大；
评估标准动态变化，需谨慎设计以保证公平性与可比性。
对话Agent的评估不仅是衡量模型性能的手段，更是驱动系统开发优化的核心环节。其主要目的包括：
诊断性分析：系统性发现模型存在的问题与缺陷（如逻辑错误、上下文漂移、不一致行为），指导有针对性的改进策略。
优化方向探索：通过量化反馈，发现提升空间（如增强长程记忆、提高任务完成率），促进新算法、新机制的设计。
模型优劣证明：在公开benchmark或应用场景中，提供可复现、可量化的评估结果，验证模型性能的先进性和实用性，提升学术影响力或商业价值。此外，良好的评估体系也是对话Agent能否安全、可控、符合伦理要求的重要保障。当前研究趋势正逐步从单一的静态评估向动态、多维、用户中心的综合评估体系演进，未来发展方向包括个性化评估指标设计、长期交互性能度量、用户情绪和信任度评估等。
良好的评估对于构建可靠的AI应用程序至关重要。然而，评估LLM-based系统带来了独特的挑战。传统评估通常假设AI每次都遵循相同的步骤：给定输入X，系统应遵循路径Y以生成输出Z。但是LLM-based系统不是这样工作的。即使起点相同，系统也可能采用完全不同的有效路径来实现他们的目标。一个agent可能会搜索3个来源，而另一个agent可能会搜索10个，或者他们可能会使用不同的工具来查找相同的答案。因为我们并不总是知道正确的步骤是什么，所以我们通常不能只检查系统是否遵循了我们事先规定的“正确”步骤。相反，我们需要灵活的评估方法，以判断系统是否取得了正确的结果，同时也遵循合理的流程。
最终结果正确只是一个很重要的步骤，但在这个基础上，如何将成本约束加入，如何将所谓“最优路径”加入，并不是一个单纯的结果评估就能搞定的，更何况如果涉及到人机协作，multi-agent的精细化协作就更复杂了。
LLM作为评委如果做得好的话是可以很容易泛化应用的。研究成果很难以编程方式进行评估，因为它们是自由格式的文本，很少有一个正确的答案。LLM非常适合对输出进行评分。要注意的是在使用LLM作为评委之前，要经过人工的验证以及LLM的结果也需要经过人工抽检才好确定。
我觉得当前市场上，特别是媒体市场上有一个导向不太好，将2D的技术型工作与2C的市场产品混合报道，这种报道会带来的混淆是让入行中的读者在不断的刷新自己的认知，一会觉得应该这样做，一会觉得应该这样做。当然原因可能是多种的，有一些是开发者自己也没有想清楚定位，反正先做，有一些则是媒体寻找素材的时候只要有就发布，至于读完内容之后读者怎么想，客观上也是读者自己的判断力。我们可以浅浅的分析一下，langchain出现之后，市场很火爆，觉得它好厉害，什么都可以做。但随着时间的推移，大家开始研究它的源码的时候，会发现它里面实现了很多对生产环境没有意义的代码。最终有一个说法叫做，可以用langchain快速实现一个toy，但如果用在生产环境，那么这个程序员就是在给自己埋雷，他需要大把的时间不断的去读这个开源库的代码，然后惊讶于它的设计和实现，也惊讶于自己其他系统的设计与实现，然后在惊讶中修复出现的问题。毕竟谁的屎山不是屎山。系统设计应该与业务实际需求相结合，比如在一个纯对内部封闭使用的问答机器人场景，增加一个安全审核可以但没必要，反正所有的风险也是内部闭环。如果你的场景就不会出现上下文记忆，那么你保留langchain中的memory模块毫无意义。而如果我是langchain的开发者，那么我应该在保证上手容易的基础上，不断增加更多的功能和模块，希望开发者可以在我的库的基础上完成几乎所有的应用开发工作，这样我可以有更强大的技术影响力。如果我是业务上实际的落地者，那么我会在调研已经有的方案基础上完成对当前业务上的落地设计实现，如无必要，不增加额外的冗余模块。我认为最终我们需要拿到的一个想法是，我们试图做什么。是一个平台，它可以自动适应所有的任务？还是一个任务一个任务的设计，最终演化成为一个平台。当前属于一个前者的狂欢阶段，如果没有一个足够大的场景来牵引优秀的开发者不断投入思考在其中，那么平台框架性质的研发可以给开发者足够大的自由度和想象空间不断的施展自己的才华；后者在明确后会更容易落地和推行，在实验室闭门造车，远不如在一场场比赛中历练出来的成果：这也是deepresearch能够出现的一个重要原因，既符合OpenAI，deepseek，Anthropic等机构中的人员背景，也是一个没有上限的可探索的方向。稍微提一个，高考志愿填报也是一个很适合在当前的研究机构中推行的一个方向。
聊一下交互。交互要分为两个部分，一个是Agent之间的交互，另一个则是Agent与人之间的交互。Agent之间的交互，其实需要二者互相明确理解对方，这种情况远不如直接用hardcode来的直接有效。模型本身的不确定性并不会带来优势。就像多人协作的时候，我们往往是从不确定性开始讨论，最终会落在无歧义的文本上，来保证有下限的实现。而在Agent本身不确定性打满的情况下，希望确定一个范式，我觉得是充满难度的（https ://mp. weixin.qq. com/s/rZ8dXJrF0fTp3CMjS-jVEw）。Agent与人之间的交互，文本，语音，视觉这是基础的一些方式，在这个基础上会演进出触觉，甚至脑机接口。这都是在HCI方面可以研究的方向，而且这些我们都可以敏锐的察觉到其中存在载体的变化。所以当前有很多正在研究的方向其实是在探索一下新的交互硬件，耳机，眼镜等。不过我也在思考的一件事情是，手机的出现是怎么出现的，它的出现其实并未跟已经有的物件做捆绑，所以我可能更加倾向于一个全新的物理硬件，或许它只要可以承载IM的功能，就可以替换当前的手机。
根据上面我们讨论过的问题，可以简单得到下面的需要明确的点，在传统的一个产品开发需求的基础上
业务背景，需求和目标明确，目标要符合SMART原则
演进方向确定：确定metrics，现状和演化节奏，从而确定演进方向。
问题复杂度：当前问题复杂度有多高，又有多少专家知识可以介入
预期设置：究竟是否有足够高的下限要求，以及对上限优化需求的必要性。在这些基础信息的把握下，我们就可以明确对S/M的agent设计，对应用在探索性还是确定性占比分布，以及有多少人工干预的诉求，从而做出一个相对合理的方案选型。而现状和演进方向的确定又会在整体系统设计的选择上有多大程度需要考虑其可扩展性和通用性，毕竟武术可以锻炼身体，七步内外，枪都是又快又准的。
聊一聊一些例子。最近我更换了自己对这些系统的理解方向，我换了个角度，发现他们都是销售！我们以购物举例子，本身我们是在寻找信息：
搜索：【目标明确的找店铺】我已经有一个明确/模糊的诉求了，搜索一下获取，你们系统来满足我的诉求就好了，弹出的东西一定要能满足我的诉求，那同时夹带私货宣传一下广告也可以，但是仅限于我自己主动上钩，毕竟我不搜就没有信息给我。
推荐：【逛街】我没有诉求，逛哪里都可以，全世界都在宣传广告，我上钩可能是因为我没有目的，所以我被带跑了，但是推荐都是喂给用户的，用户是否跟着走得看用户自己。
Agenticsystem：【销售拉客】不管用户是怎么被触达到的，一旦有了接触，此时系统会满足用户的主动需求，也会通过包括但不限于推荐的手段来引诱用户做系统想要用户做到的事情。和上面两个相对最大的区别是系统可以主动拉用户，就像街边拉用户进店体验。
销售的本质是让人们的需求得到满足，这里的核心是：
定义人们的需求
找到自己能够提供的东西，并且和用户需求匹配
说服用户将二者匹配，并愿意为之买单之所以用销售这个概念则是因为当一个system具备了一定主动性，则此时它的行为就开始超出人类的预期了，那么我们需要说服用户buyin我的行为。最简单的方式是branding。就像人们默认相信大牌产品一样，对于默认相信system的用户并非我们需要说服的目标。我们需要说服的是并不相信我们的人。how？我想雷军对比法是一种非常好用的方式，也是我们的agent最容易采取的方式。【https ://www. zhihu.com/tardis/zm/art/616225757?source_id=1003】
是评估模块的一个延伸，并非优化方向的指明，而是自证。这是我认为未来的agent需要发展的一个重要方向。说服别人～在进行产品介绍时，对不同的人用不同的举证方式。对于懵逼的外行来说，用大牌来做对比，通过对比，强调对自己有利的信息，对自己不利的缺点则避而不谈，从而突出自家产品优点、价值的营销方式。对于“所谓的”业内人士来说，将厉害的参数透出，让对方知道自己的厉害。举例：
参数透出
本文高达1w字，参考了上千篇论文，请教了上百位教授和多名专家，作者受我国589计划高校，世界top1k高校教育，并拥有世界5k强互联网企业工作经验。通过调查我们发现，但凡具备上述素质的作者所生产内容均由极高的学习和分享价值，并且只要看过之后略微点赞，升职加薪，彩票高中，身边的人高考大捷！
OK，基于上面的例子，所以我提出的观点是，不要总想着迎合用户的诉求，你需要考虑营销自己的idea给用户，用户在使用你的系统的时候，有一个底线预期是你满足我的疑惑，但还有个上升预期是你可以猜到我的顾虑，并且打消。提供引用材料是一种方式，但就像是面试的时候给面试官：诺，你看，这些材料我觉得都能回答你的问题。你看着办吧
导向个性化内容呈现，以生成内容与原始内容协同存在。
我们来以小红书为例分析一下里面的角色，内容创作者，平台，内容消费者。其中内容创作者如果想要得到更多人关注，那么TA会在满足平台要求下，结合自身特长的基础上关注内容消费者的需求，或者说反过来，从而得到内容消费者的正向关注。当前的AIGC，定位是创作者工具，那么它生产出什么样子的内容依然是由创作者决定的，只是一个提效的工具。创作发生在投稿前，需求分析发生在创作前，分发发生在投稿后，平台会负责将内容分发给感兴趣的人。好，我们来想一想，如果平台创作者没有能够很好的洞悉到内容消费者需求，或者说TA没有能力满足洞悉到的消费者需求怎么办？这个需求没有被满足，那么AIGC就可以成为平台创作工具。这个是一个很重要的点，洞悉消费者没有/无法被内容创作者满足的需求，如果只是在抢内容创作者的饭碗，那么这不是一个良好的生态，这部分工作应该会被创作者服务团队完成。所以平台的AIGC团队的重点应该是去洞悉无法被内容创作者满足的需求，自己来满足。
刚才我们讨论的核心关键有两个，一个是需求，一个是无法被满足。当我们明确这两个点之后，在分析一下平台自己的优势，一个是有大数据，另一个则是有流量侧优势——导向了基于大数据进行的用户个性化内容供应。在过去，推荐/搜索做的事情是将内容库中最满足用户需求的内容分发给用户。那么在未来，我们的内容平台还有一个很重要的工作：为每一个用户生成TA需要但库里没有的内容。有了这个思路之后，我们很容易就知道后续怎么做了。
希望你觉得上面的内容，或者我很有趣，欢迎交流，欢迎关注。
不要纠结一个系统究竟是不是agent，就当他是
评估一定要动静结合，要能指导系统的进一步演化迭代
要用做销售的心态来做agent，销售同学才是未来
可以点关注，每个月我会重新review并优化部分内容，分享更多对问题的思考
进技术交流群请添加AINLP小助手微信（id:ainlp2)
请备注具体方向+所用到的相关技术点
关于AINLP
AINLP是一个有趣有AI的自然语言处理社区，专注于AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。
