Tallate

该吃吃该喝喝 啥事别往心里搁

TALLATE / PERSONAL KNOWLEDGE INTERFACE

探索 Tallate

一个从后端系统走向 AI Agent 的工程师，正在思考、构建和记录什么？

发表于 更新于 分类于

摘要

  • 长期记忆是上下文中关键组成部分，长期记忆一般是短期记忆的沉淀，从过去的经验中学习，让用户可以记忆多轮对话的关键信息，得到处理问题的一般模式，

    Without proper memory systems, AI applications would treat each interaction as completely new, losing valuable context and personalization opportunities.

  • 长期记忆作为RAG的一部分，长期记忆的抽取和检索一般是通过RAG来实现，增强大模型回答领域问题的能力，而预训练专注于一般性问题的回答性能，例如langextract,LightRAG这样的框架
  • 使用文件存储长期记忆，按需召回，可以避免上下文超长的问题，例如manus的做法
  • 长期记忆又可以分为Semantic、Factual、Episodic，实践中一般会按抽取主体不同，按需建立不同的索引，例如mem0
  • 使用ReAct模式的Agent来管理Memory可以提供一些自主性，让Agent根据上下文和多轮的任务来自我进化，例如LangGraph MemoryAgent, QwenAgent, A-Mem, MemU

从短期记忆加工长期记忆

long_term_process

LangGraph - MemoryTemplate

memory_template_process.png
MemoryTemplate是LangChain AI提供的长期记忆服务模板，用于构建和部署可连接到任何LangGraph代理的长期记忆服务，实现用户范围的记忆管理。

  • 使用 @functools.lru_cache 定义长期记忆的过期机制
  • 使用State定义长期记忆的入参，可见本质上是对短期记忆的持久化处理
    1
    2
    3
    4
    5
    class State(TypedDict):
        """Main graph state."""

        messages: Annotated[list[AnyMessage], add_messages]
        """The messages in the conversation."""
  • memory_graph被标记成一个入口点，相当于一个接口

参考文档
https://github.com/langchain-ai/memory-template

长期记忆的提取是一个RAG模式的实现

langextract

LangExtract是一个Python库，使用LLM从非结构化文本文档中提取结构化信息，基于用户定义的指令。它能够处理各种材料，如临床文本、法律文件、学术论文等，并输出结构化的JSON数据。

核心特性

  • 精确源定位：每个提取的实体都包含精确的源文本引用
  • 可扩展性：支持处理长文档和并行处理
  • 自定义提取：通过提示词和示例控制提取行为，从非结构化文本中提取实体、关系和属性

技术架构

  • 基于LLM的信息提取
  • 支持自定义模型提供商
  • 提供插件系统扩展功能
  • 支持本地和云端模型部署

引用链接

MemoryScope

定义一个pipeline来处理记忆
https://github.com/modelscope/MemoryScope

LightRAG

定义
LightRAG是一个简单且快速的检索增强生成（Retrieval-Augmented Generation）系统，专注于提供高效的知识检索和生成能力。

  1. 智能检索：基于语义相似度的文档检索
  2. 上下文增强：为LLM提供相关上下文信息
  3. 知识图谱：利用图结构增强检索效果
  4. 实时查询：支持实时文档查询和生成

为Memory建立索引和检索

https://blog.langchain.com/semantic-search-for-langgraph-memory/

文件系统作为长期记忆的载体

Manus - 使用文件系统作为终极上下文

现代前沿LLM虽然提供128K+令牌的上下文窗口，但在真实代理场景中仍面临三个痛点：观察结果庞大容易超出限制、长上下文导致性能下降、以及高昂的计算成本。
传统压缩策略虽然能缩短上下文，但过度压缩会导致信息丢失。代理需要根据所有先前状态预测动作，无法预测哪个观察结果在后续步骤中变得重要，因此任何不可逆的压缩都带有风险。
文件系统作为终极上下文解决了这些问题：大小不受限制、天然持久化、代理可直接操作。模型学会按需写入和读取文件，不仅用作存储，还作为结构化的外部记忆。
我们的压缩策略设计为可恢复的：保留URL可移除网页内容，保留文档路径可省略文档内容。这样既能缩短上下文长度，又不会永久丢失信息。
这种基于文件的记忆方式也为状态空间模型(SSM)在智能体中的应用开辟了新可能。SSM虽然缺乏完整注意力机制，但通过将长期状态外部化而非保存在上下文中，其速度和效率可能开启新型智能体时代。

use_file_system_as_context.png

参考文档
https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

构建不同的长期记忆索引

Mem0

Mem0将长期记忆划分为不同的类型，并通过api上增加agent_id, user_id, run_id进行索引

记忆类型分类：

短期记忆 (Short-Term Memory)

  • 对话历史: 最近的对话消息及其顺序
  • 工作记忆: 临时变量和状态信息
  • 注意力上下文: 当前对话的焦点

长期记忆 (Long-Term Memory)

  • 事实记忆 (Factual Memory): 存储用户信息、偏好和领域特定知识
  • 情节记忆 (Episodic Memory): 过去的交互和体验
  • 语义记忆 (Semantic Memory): 概念理解及其关系

记忆特征对比：

类型 持久性 访问速度 使用场景
短期记忆 临时性 即时 活跃对话
长期记忆 持久性 快速 用户偏好和历史

Mem0长期记忆实现方式：

  1. 使用向量嵌入存储和检索语义信息
  2. 跨会话维护用户特定上下文
  3. 实现高效的相关历史交互检索机制

核心价值：
AI系统需要记忆系统实现三个关键目标：

  • 在对话中维持上下文
  • 从过去的交互中学习
  • 随时间构建个性化体验

参考
https://docs.mem0.ai/core-concepts/memory-types
https://docs.mem0.ai/open-source/graph_memory/overview#add-memories

进化的记忆

结合Agent的ReAct范式，实现Agentic RAG，由Agent自主判断记忆的抽取和持久化

MemoryAgent

memory_agent_process.png

LangGraph ReAct Memory Agent - 一个具有记忆保存工具的ReAct风格智能体示例。

核心特性：

  • 基于ReAct范式的智能体，能够自主判断记忆的抽取和持久化
  • 提供store_memory工具，让智能体保存重要信息供后续使用
  • 记忆按user_id作用域隔离，支持跨对话线程学习用户偏好
  • 集成LangGraph Cloud部署，支持API交互

工作原理：

  • 智能体从记忆图的Store读取已保存的记忆
  • 调用工具时自动路由到store_memory节点保存信息
  • 支持自定义记忆结构（content + context）
  • 可配置不同的LLM模型（默认Claude-3.5-Sonnet）

应用场景：

  • 跨会话保持用户偏好记忆
  • 重要信息的持久化存储
  • 智能体学习能力的增强

参考
https://github.com/langchain-ai/memory-agent?ref=blog.langchain.com

A-mem

https://arxiv.org/pdf/2508.08997
https://github.com/agiresearch/A-mem
https://zhuanlan.zhihu.com/p/1888290059859514793
https://github.com/landing-ai/agentic-doc

QwenAgent

Qwen-Agent采用三级处理框架，先通过BM25检索关键词定位核心段落，再评估分块相关性，最后逐步生成答案，实现百万字级上下文处理。

1. 上下文截断机制

qwen_agent/llm/base.py#_truncate_input_messages_roughly 中实现了基础的上下文长度管理，根据最大长度来截断messages：

  • 默认最大输入token数为58000（可通过DEFAULT_MAX_INPUT_TOKENS配置）
  • 使用tokenizer.count_tokens和truncate实时统计token数并按最大token数阈值截断
  • 保留系统消息和最新的用户消息
  • 从旧消息开始截断，确保最重要的上下文保留

2. Memory对话记忆管理

qwen_agent/agents/memo_assistant.py 实现了对话记忆功能：

  • 使用storage工具存储重要信息
  • 在对话过程中，你可以随时使用storage工具来存储你认为需要记住的信息，同时也随时可以读取曾经可能存储了的历史信息
  • 这将有助于你在和用户的长对话中，记住某些重要的信息，比如用户的喜好、特殊信息、或重大事件等

关于数据存取，有以下两点建议：

  1. 存一条数据的key尽量简洁易懂，可以用所记录内容的关键词
  2. 如果忘记存过什么数据，可以使用scan查看记录过哪些数据

此处展示当前你存入的所有信息，因此你可以省去专门读取数据的操作：

1
2
3
<info>
{storage_info}
</info>

你的记忆很短暂，请频繁的调用工具存储或读取重要对话内容。

  • 自动截断对话历史，保留最近的对话
  • 将存储的信息嵌入系统提示中

3. RAG文件知识库管理

qwen_agent/memory/memory.py#_run，messages中的文件会被保存在知识库中，检索和query最相关的部分内容，而不是将整个文件抛给llm：

  • 支持多种文件格式（PDF、Word、Excel、TXT等）
  • 使用RAG（检索增强生成）技术
  • 可配置的检索策略和关键词生成

4. DialogueRetrievalAgent - 超长对话管理

qwen_agent/agents/dialogue_retrieval_agent.py：

  • 将长对话存储为文件
  • 基于检索的历史对话查询
  • 会话级别的历史管理

qwenagent_rag.png

5. VirtualMemoryAgent - 虚拟内存管理

qwen_agent/agents/virtual_memory_agent.py 针对messages中出现的文件名，自动通过deepsearch的方式来检索：

  • 先由llm来决定使用什么工具处理这些文件，然后调用这些工具
  • 直到达到最大调用次数20次，或不再产生新的toolcall
  • 自动检索外部资源
  • 动态更新上下文知识
  • 智能工具调用

参考文档
https://qwenlm.github.io/zh/blog/qwen-agent-2405/
https://github.com/QwenLM/Qwen-Agent
https://community.modelscope.cn/682d45a3870cef736060aaef.html

MemU

MemU采用背景进程对记忆进行加工和抽取，并建立联系存储到图库中，形成自我进化

参考
https://github.com/NevaMind-AI/memU

发表于 更新于 分类于

概述

基础的 ReAct 模式将action描述为 tool ，tool为沟通世界的桥梁，但tool可以有多种解释，比如mcp as tool, agent as tool, task as tool, human as tool(human in loop)等等，task是一种进阶的能力，它是一个需要多agent配合达成的目标。
看了几种实现，可以观察到一个规律：

  • 通过一个reasoning过程来产生plan，这个plan可以在内存中，也可以被保存到一个文件，如manus的todo.md 和 cline 的 Deep Planning
  • 将plan出的任务分派给agent来执行，分配给一个agent，或多个agent来解决复杂的问题，如 claude的sub task机制 和 langgraph的Hierarchical Agent Teams机制
  • 多个task之间应该会有上下文隔离和共享机制，既需要避免上下文爆炸，又需要在某些情况下多agent之间的信息共享

claude sub task

claude_task.png
某些实现会创建 Task 给一组 Agent 执行，这意味着工具实现具有很大自由度。例如 Claude Code 将子任务执行封装为 task 工具，执行结果返回给调用该工具的 agent，并合并到主 Context 中

参考文档
Claude Code Task工具与Agent架构完整技术实现分析

langgraph Hierarchical Agent Teams

hierarchical_agent_teams_process.png
随着智能体系统的发展，单一智能体可能会遇到工具选择困难（工具过多时决策质量下降）、上下文复杂度失控（难以跟踪复杂上下文）以及专业化需求（需要多个专业领域）等问题。多智能体系统通过模块化（独立开发维护）、专业化（领域专家智能体）和控制性（显式通信控制）三大优势来解决这些问题，将复杂应用分解为多个小型、独立的智能体，通过层次化组织实现任务分解和协作，使用LangGraph构建智能体网络并通过状态图管理交互。
在langgraph中可以将task分配给一个 MultiAgent 的 Team 来执行

参考文档
Hierarchical Agent Teams
AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation

manus todo.md

manus 在处理复杂任务时，倾向于创建一个todo.md文件——并在任务进行过程中逐步更新它，勾选已完成的项目。

参考文档
https://manus.im/zh-cn/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

cline deep planning

Cline 的深度规划（Deep Planning）是一种基于上下文工程的智能体规划方法，通过系统性的上下文管理来优化 AI 系统的决策和执行能力。

深度规划的本质

  • 将复杂的任务分解为多层次、可执行的子任务
  • 通过上下文工程确保每个规划步骤都有充分的信息支持
  • 实现从高层目标到具体行动的端到端规划

上下文工程在深度规划中的作用

  1. Write Context（写入上下文）：将规划过程中的中间状态、决策依据等写入上下文
  2. Select Context（选择上下文）：根据当前规划阶段选择最相关的上下文信息
  3. Compress Context（压缩上下文）：对长规划序列进行压缩，保留关键信息
  4. Isolate Context（隔离上下文）：将不同规划模块的上下文隔离，避免干扰

规划状态管理

  1. 目标分解：将复杂目标分解为可管理的子目标
  2. 上下文构建：为每个子目标构建专门的上下文
  3. 规划生成：基于上下文生成具体的执行计划
  4. 执行监控：监控执行过程，动态调整规划
  5. 结果整合：将执行结果整合到整体规划中

与 ReAct 模式的对比

特性 ReAct 模式 Cline 深度规划
决策方式 即时反应式 前瞻性规划
上下文使用 简单工具调用 复杂上下文工程
任务分解 单一工具调用 多层次任务分解
执行模式 线性执行 并行+串行混合
错误处理 重试机制 规划调整机制

参考文档
https://cline.bot/blog/how-to-think-about-context-engineering-in-cline
https://x.com/shao__meng/status/1957031656692543939
https://x.com/shao__meng/status/1957682039509118989

发表于 更新于 分类于

ReAct 机制

ReAct是一种将推理(Reasoning)和行动(Acting)与语言模型相结合的通用范式，通过交错生成推理轨迹和特定任务行动来解决复杂问题，是现代大部分框架构建 Agent 的基础理论。

理论基础

核心思想

  • 语言空间中的动作(思想/推理痕迹)不影响外部环境，但更新上下文以支持未来推理
  • 推理轨迹帮助模型归纳、跟踪和更新行动计划，处理异常
  • 行动允许与外部环境交互并收集额外信息

工作机制

1. Reasoning - 通过语言推理制定高级计划，确定下一步行动

大模型推理引擎可以解析 prompt 中的 toolcalls 作为行动计划 sglang function_calling

output parser

tools_are_structured_output
另一种方案是从大模型的结构化输出中解析工具调用，而非依赖 toolcalls 能力，这种方式提供了更大的灵活性 Tools are just structured outputs

例如 ADK 的实现就采用模型的结构化输出来识别行动 ADK Planer

2. Acting - 通过外部交互获取信息，验证推理假设，更新上下文

通常使用工具（tools）进行交互，handoffs 机制可以将其他 Agent 作为可执行工具。是否定义独立 Agent 来执行 Acting 取决于任务复杂度及其价值（因为 Agent 运行成本较高）。此外，Agent 的异常恢复机制相对脆弱，可能需要 human-in-the-loop 介入，需要权衡考虑 Prompting for Agents | Code w/ Claude

plan and execute

plan_and_execute.png
当一次产生多个 Acting 时，会演进为 Plan-And-Execute 机制 Plan-and-Execute
相对ReAct机制，plan-and-execute机制具备前瞻性，每个任务的执行比较自由，可以灵活调度并行或串行执行。

3. Reasoning Loop - 重新规划，直到收敛

Agent 进行多轮循环，不断执行 Reasoning 过程。在多次循环中，Memory 会记录执行历史，Agent 基于历史不断调整策略直到问题收敛 Memory

replan

在 Plan-and-Execute 机制中称为 Re-Plan，但不同之处在于 Re-Plan 需要上下文记录 step 历史 Plan-and-Execute

适用场景

  • 知识密集型推理任务(问答、事实验证)
  • 交互式决策任务(文本游戏、网页导航)
  • 需要动态调整的复杂任务

LangGraph 中构建 ReAct Agent 的要素

react_run.png

核心运行流程

  1. 初始化阶段：用户查询 → 初始化Agent → 生成系统提示词 → 初始化上下文
  2. 多轮循环：开始ReAct循环，直到达到最大轮数或获得最终答案
  3. 推理阶段：调用LLM获取响应 → 解析LLM响应
  4. 决策分支：
    • 包含Final Answer → 返回最终答案
    • 不包含Final Answer → 解析Thought和Action → 提取工具名称和参数 → 执行工具调用 → 将工具结果添加到历史 → 继续下一轮循环

构建要素

  1. 上下文管理：定义 AgentState 管理记忆和对话上下文，构建与大模型交互的 prompt schema，进行压缩、剪枝、卸载等优化
  2. 工具：提供与外部知识库、环境交互的手段，决定 Agent 的能力范围
  3. 模型选择：模型能力影响结果质量
  4. 节点编排：设计 Agent 推理节点和工具执行节点的交互流程
  5. 终止机制：防止 ReAct 无限轮询，避免死循环和资源浪费
  6. 响应解析：解析LLM输出中的Thought、Action和Final Answer

发表于 更新于

多智能体运行模式

本文档总结了当前主流的多智能体运行模式，包括Rewoo、Plan and Execute、DeepResearch等架构模式。

阅读全文 »

发表于 更新于 分类于

Context Engineering

为什么需要Context Engineering

文章强调”Communication is all you need”的理念

  • 与LLM的沟通很困难，且经常被低估
  • 许多智能体错误的根本原因在于沟通问题
  • Context Engineering正是解决这些沟通问题的关键
    AI在应用中的表现，除了模型本身能力，更关键的是能否获取“有效且准确的context”。这里的context，不只是上下文，而是模型在特定任务下能获得的真实、相关的信息。
    Context Engineering 是为Agent在执行任务的每个步骤中，精确地向上下文窗口填充恰当信息

构成

主要包含数据源的RAG、state History和Memory，然后通过Prompt Engineering来组织数据，构造模版渲染输出
rise_of_context_engineering.png

  • Prompt Engineering: Instructions for how an agent should behave are clearly enumerated in the prompt，提示词、记忆、少样本示例、工具描述.
  • Tool use: Making sure that if an agent needs access to external information, it has tools that can access it. When tools return information, they are formatted in a way that is maximally digestable for LLMs
  • Short term memory: If a conversation is going on for a while, creating a summary of the conversation and using that in the future.
  • Long term memory: If a user has expressed preferences in a previous conversation, being able to fetch that information.
  • Retrieval: Fetching information dynamically and inserting it into the prompt before calling the LLM.
阅读全文 »

发表于 更新于 分类于

概述

Open Deep Research 是一个基于 LangGraph 构建的开源深度研究系统，能够根据用户请求灵活调整研究策略，生成高质量的研究报告。该系统采用多代理架构，支持并行研究任务，并通过上下文工程优化 token 使用。

阅读全文 »

发表于 更新于 分类于

分布式系统稳定性设计

在分布式系统设计中，稳定性是最核心的要素之一。一个不稳定的系统不仅会影响用户体验，还可能导致业务损失。本文将从基本原则和具体措施两个维度来探讨分布式系统的稳定性设计。

阅读全文 »

发表于 更新于 分类于

高效汇报的艺术

汇报是职场中最重要的沟通技能之一。无论是向领导请示工作、汇报项目进展，还是寻求决策支持，一份好的汇报都能事半功倍。本文将系统性地介绍汇报的类型、核心要素和具体步骤，帮助您掌握高效汇报的技巧。

阅读全文 »

发表于 更新于 分类于

为什么需要Scrum

传统方法（主要是瀑布法）效率不足且经常引起项目最终无法交付。

Scrum团队

团队效率的提升比个人能力的提升对项目完成的影响更大
卓越团队的特点：

  1. 明确的目标
    他们具有希望超越寻常的目标。实现这种目标的动力促使他们超越寻常，达到卓越。他们下决心拒绝平庸，出类拔萃，这种决定改变了他们看待自己的方式，扩大了他们的能力范围。
  2. 自主决策能力
    这种团队自我组织，自我管理，有能力决定如何开展工作，并获得了根据自己决定做事的授权。
  3. 多功能
    这些团队具备完成项目的所有技能：计划、设计、生产、销售、分销。具有这些技能的成员相互学习，相互提高。一位设计革命性新款相机的团队成员说：“当所有团队成员都在一间大房子里办公时，某个人的信息就是你的信息，并且得来全不费功夫。你会开始思考对整个团体而言，最优选择或次优选择是什么，而不再仅仅从你个人的角度考虑问题。”
    每个团队成员都具备完成工作所需的各种技能，而不严格划分每个成员的角色，如果严格划分角色，不同角色间交流情报时就会容易产生误差。
  4. 透明度高、注重信息分享
  5. 团队规模
    如果团队规模过大，沟通渠道增多会带来更大的沟通成本。
    Scrum团队倾向于让每个成员都知道其他人在做什么，每个人正在做什么工作，正面临哪些挑战，取得了哪些进步等等，都是透明的。团队规模过大会影响沟通效果，进而导致团队分裂成小团体，以至于多功能的团队就不复存在了。
  6. Scrum Master
    制订工作框架：冲刺、每日立会、检查与回顾。
    Scrum Master负责确保整个工作流程的顺利推进，他的工作职责是召集会议，确保团队运作过程的透明度，为团队发现障碍，并持续改进。
  7. 工作制度
    不要把问题归咎于某一个人，而是寻求制度上的解决方案。

周期

  1. 冲刺
    冲刺指的是项目中的一个小的迭代周期，叫冲刺会比较有紧张感。
    每个周期固定时间审视一下这个周期内团队成员做的成果
    冲刺周期是固定的，有固定期限可以让团队成员方便评估自己的节奏在每个周期能做多少事情，并且不允许团队之外的任何人给团队内成员增加任务。
  2. 每日立会
    了解这个冲刺周期内各项任务的进展状况，有没有障碍，需不需要其他人来帮忙；团队的一切任务都是自主决定、自主完成的，不需要汇报。
    时间不宜过长，不应给团队带来负担。
    Scrum Master每日问3个问题示例：
  • 你昨天做了什么去帮助团队完成冲刺；
  • 今天你打算做什么来帮助团队完成冲刺；
  • 什么因素阻碍了团队的前进之路？
    每日立会规则：
    一、每天会议召开的时间是固定的，每个成员都要出席；
    二、开会时间不能超过15分钟，每次开会都直击重点，如果有事情需要进一步讨论，可以先记录下来，在每日立会结束之后再做进一步的讨论；
    三、每个人都要积极参与，尽量让每个人都站起来开会。

避免浪费（人力）

  1. 一次只做一件事
    研究报告指出，哪些最喜欢同时执行多项任务的人自制能力相对较弱，没有办法让自己长时间集中精力。
    同时执行多项任务一般不会加快速度，反而会拖累。
  2. 一次把事情做完
    Scrum开发过程中的工作是有节奏的。每一个迭代期，或者说每一个冲刺期，团队都试图完成很多事情。但是“完成”意味着一款能被消费者使用的、完整的、可交付的产品。如果在迭代期的最后，事情只做了一半，你将比一点都没开始做更糟糕。你花费了资源，付出了努力和时间，最后没有得到任何成果。

一次把事情做对

如果你出了一个错误（我们都会出错），那就在发现错误时立即修改，不然就会付出代价。
生产流程应该是持续改进的，而处理问题的最佳时机是你发现问题的时候，而不是发现问题之后很久再着手解决。
出现问题不立即修复，而是放到很久之后，会浪费更多时间：当你在做一个项目的时候，大脑专注于它，你很清楚做某件事的所有原因，这时你的脑子里存在一个与之相关的复杂架构，想在几个星期后重新建立这样的架构十分困难，会花费更多时间。

工时越长，效率越低

马克思韦尔曲线
工作时间太长的人会开始犯错，而改正错误可能会比创造新成绩花费更多的时间。工作超出负荷的员工比较不容易集中注意力，而且会影响别人也跟着分心，不久之后他们就会开始做出错误决策。
这意味着我们更应该关注完成任务的时长和质量而不是工时长短。

确保工作的合理性

有几种不合理现象：
1、目标荒谬、不切实际
2、期待过高
3、负担过重，比如繁琐的规定、没必要的汇报、会议等过多
4、情绪浪费，比如团队中某个人倾向于激怒别人、削弱团队斗志。

周期规划会

给项目划分任务
确立优先级：由产品负责人决定优先级
确定需要花费多少精力、时间和资金。怎么知道自己的速度？每个成员冲刺周期结束时复盘可以知道自己的效率如何，并且可以通过消除障碍来变得更快
让执行团队评估自己的工作
用用户故事描绘任务：角色、活动、商业价值
用户故事必须完整：独立性、可协商性（不要带太多细节）、有价值、可评估、规模小、可测试
用户故事来源：需要产品负责人拿出一半时间与购买产品的客户开展对话（了解客户对于最新产品的看法，看看自己的产品是否为客户创造了价值），还要拿出一半时间拟定待办事项清单（让团队成员知道客户重视什么、不重视什么）。

产品负责人的特点

  • 第一，产品负责人需要在相关领域内掌握丰富的专业知识。
  • 第二，产品负责人必须获得自主决策权。
  • 第三，产品负责人必须有足够的时间与团队成员接触，向团队成员解释清楚需要做什么以及为什么要这么做。
  • 第四，产品负责人必须为价值负责。

信息瀑布：人们倾向于遵从之前众人的行为 - 别人的评估意见只能拿来作为参考，以便改进自己的判断，而不是完全取代自己的判断。
光环效应：是指当认知者对一个人的某种特征形成好或坏的印象后，还倾向于据此推论该人其他方面的特征，本质上属于以偏概全的认知错误 - 评估时保证匿名性，减少互相影响
拥抱变化：一般最初的计划评估不会完美，关键在于，要在项目执行过程中及时加以调整和改进，而不是刻板地遵循计划。详细规划出能够创造出新价值的部分，至于项目中的剩余部分，计划粗略一些也无所谓。每个冲刺周期结束之际，都必须为顾客展示一些看得见、摸得着的新价值。你可以问顾客一些问题，比如，这是你要的吗？这能帮你解决一些问题吗？我们的方向是对的吗？如果答案是否定的，那么你就要修改你的计划。

二八原则

往往20%的功能可以覆盖80%的价值
1、根据产品负责人对需求优先级的排列可以确定最重要的那部分需求
2、先做最重要的MVP部分，以期快速得到市场反馈，在此基础上检查和调整产品

风险

Scrum的目的之一是降低项目研发过程中的风险，常见的风险是市场风险、技术风险和财务风险。
市场风险：Scrum注重渐进式迭代，每个周期通过show case将产品展示给客户，收集用户意见，因此可以实时对产品做出小改动，不必等到投入大量成本后再被迫做出改动。
技术风险：先做几种原型，实际加以比较。
财务风险：怎么发现自己做的产品能挣到钱？渐进式迭代+showcase

0%